SEGMENTATION FAULT in newest version, but none in the old.

[rikky]

Disclamer : I have thrown away my old BaCon version, so I cannot test it for real, but I am pritty sure the following is true. 

I recompiled an old program with the newest BaCon 

BaCon version 3.9.3 on Linux armv7l - (c) Peter van Eerten - MIT License.

And now suddenly it gave a 

ERROR: signal for SEGMENTATION FAULT received - memory invalid or array out of bounds? Try to compile the program with TRAP LOCAL to find the cause.

Pffff, rather a big program, and even when I located the error, I could not see what was wrong with it.

Eventualy I found it, and YES I made an error in the original program.

If you compile :

FOR word$ IN bla$
NEXT word$
You get an 

Compiler error:
Description:
file 'test.bac' line 4: FOR word$ IN bla$
Cause:
'bla$' undeclared (first use in this function)

But if you add some impossible condition :

IF 1 = 3 THEN bla$ = "bloep"

FOR word$ IN bla$
NEXT word$
Then the program compiles just fine.

But formerly the bla$ was interpreted like an empty string, and the FOR NEXT loop was not executed.
Now I get a SEGMENTATION error.

Or so I think, for I have used my program numorous times.

Also, I get the SEGMENTATION ERROR, but the exitcode is zero. 

Thanks, Rik 

Edit:
P.S  I just tested it with version 3.9.1
and indeed it doesn't give a Segmentation fault.

[Pjot]

Hi rikky,

Thanks, I see what you mean, it is reproducable on my plain x86_64 system as well.

In 3.9.3 the FOR..IN statement uses the core engine for delimited strings, and this engine cannot handle a situation where the variable for the loop is not defined. That is the cause of the segfault.

So the code in the client program is wrong, however, BaCon should not produce a segfault here.

From functional point of view, I am not sure if we can call this a bug, because all works correctly when we pass a valid string variable to the FOR..IN loop. This is similar to programming C directly. But for BaCon, it is confusing, and above all, it can be easily fixed (see fossil repo, fix already in place).

Regarding your impossible condition, it defines the variable after the FOR..IN statement, so that is too late. The segfault will appear nevertheless.

If you fetch the code from the repo then you'll see the segfault does not appear anymore.

Thanks for reporting,
Peter