FB 1.03 Linux to Win/Dos difference.
Re: FB 1.03 Linux to Win/Dos difference.
I would think that if a variable is defined as string*7, then it shouldn't matter what those bytes are. They should copy, print, etc. Of course passing a string with nulls to a C routine that expects a null-terminated string will truncate of course. But the "s2=s1" line should give you a full copy, nulls and all! At least in the case of copying the string to another variable, I'd say that's a bug in the runtime.
-
counting_pine
- Site Admin
- Posts: 6323
- Joined: Jul 05, 2005 17:32
- Location: Manchester, Lancs
Re: FB 1.03 Linux to Win/Dos difference.
There are several cases of less than well-defined behaviour in FB's String*N.
Ideally they should look in memory like an array of exactly N bytes, behave functionally like a String of length N, and on assigning as if LSet were called.
But internally they use - and often rely on - a null terminator, which breaks all these assumptions.
Additionally, I think it pads with nulls rather than spaces on assignment.
In their current state, I can't think of any case I'd suggest using them. Particularly if it depends on behaviour we might fix in a later release.
Ideally they should look in memory like an array of exactly N bytes, behave functionally like a String of length N, and on assigning as if LSet were called.
But internally they use - and often rely on - a null terminator, which breaks all these assumptions.
Additionally, I think it pads with nulls rather than spaces on assignment.
In their current state, I can't think of any case I'd suggest using them. Particularly if it depends on behaviour we might fix in a later release.