Page 1 of 1
Bug in Strings.StringToReal
Posted: Mon Apr 15, 2019 4:54 pm
by Robert
The Docu says "Post s is legal real number representation".
In the following fragments
Code: Select all
x: REAL; res: INTEGER;
BEGIN
(* x := 68034D24; *)
Strings.StringToReal ('68034D24', x, res); HALT (88)
one can see that
68034D24 is not legal - the compiler rejects it, but
StringToReal does not.
I think this is a bug.
Re: Bug in Strings.StringToReal
Posted: Mon Apr 15, 2019 5:16 pm
by Josef Templ
I am sure that this has been introduced for compatibility with Oberon(-2) LONGREAL literals
whch used to be notated with a "D" instead of an "E" for REAL.
- Josef
Re: Bug in Strings.StringToReal
Posted: Mon Apr 15, 2019 5:47 pm
by Robert
I am not concerned by the 'D' rather than 'E', but with the lack of a '.'.
The string 68034E24 behaves the same.
The real issue is the incompatibility between the compiler and the library.
Re: Bug in Strings.StringToReal
Posted: Mon Apr 15, 2019 9:50 pm
by Josef Templ
The docu does not define what "legal" means. Legal according to which laws. Can be CP or other grammar.
For StringToInt it defines the grammar, for StringToSet it defines that it is the CP SET notation, but for Reals it leaves "legal" open.
The only explanation I can find, and it is speculative, is that oms wanted to be tolerant when reading and converting
user input e.g. from a Text control bound to a REAL.
It may also be an error of course.
- Josef
Re: Bug in Strings.StringToReal
Posted: Tue Apr 16, 2019 7:40 am
by Robert
While I was surprised by 68034D24 being accepted as a REAL (in my context it was actually a HEX representation of a SET) I have changed my mind about this being a problem.
I now think it is better to leave StringToReal unchanged.