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.)
1. 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.
2. 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'.
3. 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 -- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707