PRINT bloep$ fails

[rikky]

My latest post was really an embarrassment.
I hardly ose to report again.
8 out of ten things that I report are from my own mistakes.

But since Bacon is designed for people like me, that are not the brightest, I took all my courage together to report again.

I 'm using the latest Fossil from today,  or so I think.

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

And I have again a program with an impossible comparison.

blie$ = "one"

IF 1 = 2 THEN
bla$ = "two"
END IF

bloep$ = "three"

PRINT blie$ & " " & bla$ & " " & bloep$
And the response is 

one

No error during compiling, neither during runtime.

It forgets the bloep$  

 Rik.

[Pjot]

Ha! Rikky strikes back with a vengeance

Though this behavior looks strange, it is "as-designed", and it has been this way since the very beginning of BaCon.

The reason this happens is that the string concatenation makes use of so-called "variable argument lists" in C.

As the C-code does not know how many elements the string concatenation will have, it looks for an end-marker, or a sentinel. So the sentinel is a NULL-string, and as soon a NULL-string occurs, the string concatenation bails out.

Your sample code leaves the variable "bla$" uninitialized because the IF-THEN is impossible. So "bla$" will have the value NULL.

Then the string concatenation will stop concatenating elements as soon as it encounters "bla$".

Again, this behavior has been there since the first implementation of string concatenation in 2009. Even so, we may now rethink this situation and wonder if we cannot do something about it.

There are multiple solutions possible, of which I have chosen the most optimal one (I think): the CONCAT macro will calculate the amount of elements and pass the result to the C-code.

If you fetch the latest beta you'll see your code now will show a different result.

Thanks for reporting,

BR
Peter