Hi!
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'.
1. Does Borland Pascal do teh same, or is it a GPC bug?
2. Is the base prefix a GNU Pascal extension, or is it present in BP too (relevant for docs page)?
3. Val ('$100000000, x, ec) gives x := 0; ec := 0;
There seem to be no indication of overflow error in this case.
Thanks, Mirsad
program val; uses GPC; var i, ec: Integer; s : String; begin repeat ReadLn (s); Val (s, i, ec); WriteLn (i, ' ', ec); until i = 1000 end.
bash-2.05b$ gpc --automake val.pas val.pas:4: warning: missing string capacity -- assuming 255 bash-2.05b$ a.out 12#11 13 0 12#11invalid 0 7 16#ffffg 65535 8 12#11c 13 6 12#11i 13 6 12#11in 0 7 12#11cc 0 7 $ffff 65535 0 $ffffg 65535 6 $ffffgg 0 7 $ffffffff -1 0 16#ffffffff -1 0 $100000000 0 0
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
Frank Heckenbach wrote:
Mirsad Todorovac wrote:
- 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.
From the Turbo Pascal 6.0 Library Reference:
"Val( S: String; var V; var Code: Integer)"
"... If the string is somehow invalid, the index of the offending character is stored in Code; otherwise, Code is set to zero.
Val performs range-checking differently depeding on the state of {$R} and the type of the parameter V.
With range-checking on, {$R+}, an out-of-range value always generates a run-time error. With range-checking off, {$R-}, the values for an out-of-range value vary depending upon the data type of V. If V is a Real or Longint type, the value of V is undefined and Code returns a nonzero value. For any other numeric type, Code returns a value of zero, and V will contain the results of an overflow calculation (assuming the string value is within the long integer range)."
"... Restrictions. Trailing spaces must be deleted."
Regards,
Adriaan van Os
Adriaan van Os wrote:
Frank Heckenbach wrote:
Mirsad Todorovac wrote:
- 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.
From the Turbo Pascal 6.0 Library Reference:
"Val( S: String; var V; var Code: Integer)"
"... If the string is somehow invalid, the index of the offending character is stored in Code;
The question is if V is (guaranteed to be) zero then.
Frank
On 12 Aug 2003 at 21:54, Frank Heckenbach wrote:
[...]
"Val( S: String; var V; var Code: Integer)"
"... If the string is somehow invalid, the index of the offending character is stored in Code;
The question is if V is (guaranteed to be) zero then.
I wouldn't have thought so. The value of V might well be undefined. My understanding (which of course may be wrong) is that nothing is done with V unless the procedure call succeeds. So whatever was in V before the procedure call would still be there afterwards, but I do not think that even this is guaranteed.
Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Web: http://www.bigfoot.com/~african_chief/
Prof. A Olowofoyeku (The African Chief) wrote:
On 12 Aug 2003 at 21:54, Frank Heckenbach wrote:
[...]
"Val( S: String; var V; var Code: Integer)"
"... If the string is somehow invalid, the index of the offending character is stored in Code;
The question is if V is (guaranteed to be) zero then.
I wouldn't have thought so. The value of V might well be undefined. My understanding (which of course may be wrong) is that nothing is done with V unless the procedure call succeeds. So whatever was in V before the procedure call would still be there afterwards,
This would seem reasonable, but apparently not what BP does. This gives `0 3'.
program Foo; var x, y: Integer; begin x := 10; y := 20; Val ('34c', x, y); WriteLn (x, ' ', y) end.
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.
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.)
Frank
On 13 Aug 2003 at 23:44, Frank Heckenbach wrote:
Prof. A Olowofoyeku (The African Chief) wrote:
On 12 Aug 2003 at 21:54, Frank Heckenbach wrote:
[...]
"Val( S: String; var V; var Code: Integer)"
"... If the string is somehow invalid, the index of the offending character is stored in Code;
The question is if V is (guaranteed to be) zero then.
I wouldn't have thought so. The value of V might well be undefined. My understanding (which of course may be wrong) is that nothing is done with V unless the procedure call succeeds. So whatever was in V before the procedure call would still be there afterwards,
This would seem reasonable, but apparently not what BP does. This gives `0 3'.
program Foo; var x, y: Integer; begin x := 10; y := 20; Val ('34c', x, y); WriteLn (x, ' ', y) end.
It does so here as well. So does FPC. However, Delphi (from v3.0 to 7.0) produces "34 3".
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?
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).
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~african_chief/
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
On Thu, 14 Aug 2003, Frank Heckenbach wrote:
Prof A Olowofoyeku (The African Chief) wrote:
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.)
I was thinking about how having the sane part of string converted and stored could provide extra functionality - that would add a means for the function to be used in i.e. numerical expressions parsing at little extra cost, since the number appears to be already converted (the right value appears in `x' in the case of only one invalid char).
Of course, provided that this is what we want. We could OTOH want either completely 'clean' string or nothing.
I can't tell the number of program's that do rely on BP or Delphi `Val' undocumented behavior.
Frank?
Mirsad
Mirsad Todorovac wrote:
I was thinking about how having the sane part of string converted and stored could provide extra functionality - that would add a means for the function to be used in i.e. numerical expressions parsing at little extra cost, since the number appears to be already converted (the right value appears in `x' in the case of only one invalid char).
Of course, provided that this is what we want. We could OTOH want either completely 'clean' string or nothing.
I can't tell the number of program's that do rely on BP or Delphi `Val' undocumented behavior.
Frank?
As I said, I'd prefer to leave it undefined (and document it as undefined), unless we hear of a definitive behaviour of some other relevant compiler.
Frank
On Fri, 15 Aug 2003, Frank Heckenbach wrote:
Mirsad Todorovac wrote:
I was thinking about how having the sane part of string converted and stored could provide extra functionality - that would add a means for the function to be used in i.e. numerical expressions parsing at little extra cost, since the number appears to be already converted (the right value appears in `x' in the case of only one invalid char).
Of course, provided that this is what we want. We could OTOH want either completely 'clean' string or nothing.
I can't tell the number of program's that do rely on BP or Delphi `Val' undocumented behavior.
Frank?
As I said, I'd prefer to leave it undefined (and document it as undefined), unless we hear of a definitive behaviour of some other relevant compiler.
OK.
Mirsad
On Tue, 12 Aug 2003, Frank Heckenbach wrote:
Adriaan van Os wrote:
Frank Heckenbach wrote:
Mirsad Todorovac wrote:
- 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.
From the Turbo Pascal 6.0 Library Reference:
"Val( S: String; var V; var Code: Integer)"
"... If the string is somehow invalid, the index of the offending character is stored in Code;
The question is if V is (guaranteed to be) zero then.
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.
Mirsad
-
Adriaan van Os -
Frank Heckenbach -
Mirsad Todorovac -
Prof A Olowofoyeku (The African Chief) -
Prof. A Olowofoyeku (The African Chief)