Mirsad Todorovac wrote:
We spoke earlier about the problem with ec in
Val (source, x, ec)function, and Frank said it will be fixed in next release (it's exhibited again in '12#11invalid').
Consider the following second problem that `Val' returns '0' if he finds more than one non-digit character in `source' string. If there's only one or zero erroneous digits at the end of number, `Val' converts the number to `x'.
That was another symptom of the same bug, fixed now. (Feel free to add a test.)
- Does Borland Pascal do teh same, or is it a GPC bug?
Now I'm surprised. BP seems to always set x = 0 when ec <> 0, i.e. when invalid characters are found.
Can any BP user confirm whether that's the expected behaviour? (I've always used `Val' for entire number strings, so ec <> 0 would be an error in my programs, so I've never noticed this behaviour.)
If that's really so in BP, I suppose we should change it in GPC.
- Is the base prefix a GNU Pascal extension, or is it present in BP too (relevant for docs page)?
BP allows `$' in `Val'. It doesn't know about `16#' at all, so of course also not in `Val'.
Val ('$100000000, x, ec) gives x := 0; ec := 0;
There seem to be no indication of overflow error in this case.
As always in GPC (so far). It might be caught by range-checking soon (you might want to add a test), but if the actual value exceeds the range of LongestInt, it may not (overflow checking in general in another topic) ...
Frank