Bug in Strings.StringToReal

[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.

[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

[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.

[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

[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.