|
Post by rikky on Dec 27, 2019 18:26:35 GMT 1
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. 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.
|
|
|
Post by Pjot on Dec 27, 2019 21:47:17 GMT 1
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
|
|