hibtc / MAD-X

66%

master: 54%

LAST BUILD ON BRANCH fix-grow-empty-array

branch: fix-grow-empty-array

CHANGE BRANCH

x

Reset

• fix-grow-empty-array
• bugfix-select
• cd-command
• cleanup
• cleanup2
• cleanup_command_par
• cmake-cxx11
• cmake-nptsa
• cmake-static-archive
• coverage-ci
• doc-shared-drift
• find_table
• fix-amux-inconsistency
• fix-aperture-plot
• fix-cmake28
• fix-delete-sequence
• fix-latexuguide
• fix-line-parsing
• fix-mvar
• fix-parsing-logical-after-string
• fix-select
• fix-select-class-variable
• fixup
• fortran-coverage
• gc-8.0.2
• hotfix
• intel-cmake
• intel-cmake-rel
• manylinux
• master
• multipole-kick
• nmass
• opt_X11
• per-constraint-weights
• read_table
• sectorfile
• shared-drifts
• srotation_angle_survey
• tests-interpolate
• tmbend-interpolate-k0
• travis-maint
• travis-test-plot
• various-fixes

Build # 23

Build Type

push

travis-ci

Committed by coldfix

Commit Message

Fix growth of zero-length arrays

In many places the `grow_XXX_array` functions are used to allocate an
additional array element directly before writing into the supposedly
allocated array index without further range-checks.

Now, if an array was initialized to zero length it was never grown,
meaning that we would write after the end of the allocated buffer.

This just caught me with the `select->at` parameter which has to have
zero length by default (as defined in mad_dict.c). If you specify one or
two values for `at`, everything *seemed* to work as expected. However,
`decode_par` did not properly grow the double array and was writing the
values after the end of the buffer. When specifying a third argument,
the problem manifested by writing a NUL into the first byte of the
`flag` buffer and hence not anymore executing any selection routine.

I need at least grow_double_array/grow_expr_list to make this work.

Note: we could alternatively fix this by always allocating at least an
`max=1` array to begin with.

Run Details

11901 of 17938 relevant lines covered (66.35%)

807414.33 hits per line