Bug in Strings.StringToReal

Post Reply
User avatar
Robert
Posts: 1024
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Bug in Strings.StringToReal

Post 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.
User avatar
Josef Templ
Posts: 2044
Joined: Tue Sep 17, 2013 6:50 am

Re: Bug in Strings.StringToReal

Post 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
User avatar
Robert
Posts: 1024
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: Bug in Strings.StringToReal

Post 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.
User avatar
Josef Templ
Posts: 2044
Joined: Tue Sep 17, 2013 6:50 am

Re: Bug in Strings.StringToReal

Post 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
User avatar
Robert
Posts: 1024
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: Bug in Strings.StringToReal

Post 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.
Post Reply