MAD-X
MAD-X copied to clipboard
MethodicalAcceleratorDesign
Variable Name Lenth Limitation
Hi,
I've noticed MAD-X crashes for inputs of variable names that are strictly longer than 47 characters. For instance, opening a MAD-X interpreter and entering this line will have it crash:
ATS_2022_05_08_B1_arc_by_arc_coupling_133cm_30cm = -1.0;
However, removing a single character to the variable name, which brings it to 47, works:
ATS_2022_05_08_B1_arc_by_arc_coupling_133cm_30c = -1.0;
We can also confirm this is not due to a limit on the line length, as the following works too (line of 97 characters):
arc_by_arc_coupling_133cm_30cm = 1.0 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1;
In the documentation, section 2.15 Variable Names there is no mention of such a limit. There is, however, mention of a limit at 17 or 48 in Chapter 16. Conversion to SixTrack with the LONG NAMES optional flag of the SIXTRACK command. It gives the impression that the limits is only for the export to SixTrack though, and not for MAD-X itself.
Is this a bug or a known limitation of MAD-X? If so, I would be ok making a small pull request adding the caveat to the documentation.
47 characters (48 including terminating "nul") is a known limitation of MAD-X names. The crash is unexpected and a short example should allow debugging the buffer overflow. 16 characters limitation is for the export to sixtrack (sixtrack limitation) or plot strings (e.g. legend).
grep 48 src/* shows many occurrences of this limit... I guess it could be raised with some effort...
the limit is called NAME_L or something like that, 48 is almost never used...
The crash could be compiler (flag) dependent I think? The line doesn't make madx crash for me
The crash could be compiler (flag) dependent I think? The line doesn't make madx crash for me
The crash is more architecture and OS-dependent, which may align and allocate memory more conservatively, e.g. to match cache lines.
If one arch/OS combination is crashing, it means that a bug is present, and if the crash is deterministic, then this arch/OS might be the best combination to find the bug...