Closed jodavies closed 5 months ago
Regarding Vlad's request for a mode which enforces the 16-char limit, I wonder: how about an On strict;
mode which does this, but also can be used in the future for parser-related changes which make FORM more robust. In this mode, it would not be guaranteed that you have backward compatibility. If your old FORM scripts were relying on, essentially, buggy/undefined behaviour, they might break if you're using On strict;
?
I think this PR is good to merge, but before the merging maybe you would like to squash the commits into one (or I can do that). You may also write some test cases, which could be a separate PR.
A test case for this will be cleanest with #501 I think.
OK, then I will merge this PR and also #501 (I don't see any problem with this).
This doesn't actually work quite as intended. If you use a loop to save multiple expressions, as in:
#do i = 1,2
Save test-`i'.res, abcdefghijklmnop`i';
#enddo
you don't get two messages, but rather:
test-2.frm Line 18 --> Warning: saved expr name over 16 char: abcdefghijklmnop1
++++Errors in Loop
This seems to be due to the presence of the &
at the beginning of the format string (which prints the filename and line number).
This addresses #192 and #334 .
Terminating on this condition will certainly break people's existing FORM scripts.
At least print a warning, since one can certainly produce bugs by using names over MAXENAME (16) characters.
An example bug:
then
which gives:
Here,
abcdefghijklmnopqrst
is loaded with the incorrect nameabcdefghijklmnopqrstx
, andabcdefghijklmnopqrstu
is loaded asabcdefghijklmnopqrst
. ThenAbcdefghijklmnopqrst
has value21
and not20
.With the patch, upon saving, you get:
What do you think? I used MesPrint and not Warning/HighWarning since those don't take arguments for the format string.