Prof A Olowofoyeku (The African Chief) wrote:
but I do not think that even this is guaranteed.
It might still be undefined in BP. (My printed manual doesn't state it, either.) Then again, many things that are undocumented are relied upon by BP programmers and required for "full" compatibility. I don't know if this will be one of them.
Perhaps. I don't think it will harm any BP programmer if GPC guarantees it to always be zero. In a small program like the above, you may get zero all the time - but what if it was in the middle of a 1,000-line program?
It will likely be zero, but I can't tell for sure -- at least not without reading BP's RTL sources which I won't do for copyright reasons. (If someone else has them (part of BP 7.0) and doesn't plan to work on the RTS, they might want to check ...)
Mirsad Todorovac wrote:
The other side of the story is that Val could be used more flexible, i.e. for parsing if "best effort" has been done, and string has been converted-up to the first invalid character/digit.
We could do that if we decide to interpret it as undefined.
However, since `Val' is a BP function, anyway, I'd tend to change GPC's behaviour and set the number to 0. (In the case where you want to ignore the trailing garbage, it's easy to pass the prefix to `Val' again.)
What Mirsad suggests seems to be what Delphi does (i.e., stop where the error starts, and return what was possible to convert before the error - but again the Delphi help file does not document this, so I am not sure that one should rely on this behaviour).
Perhaps we should leave it undefined until/unless someone provides a reference of clearly documented behaviour of other compilers. (If that's what we do, please mention it in the reference, Mirsad.)
Frank