Eike Lange wrote:

The following program compiles correctly (shouldn't there a warning?).

Uaaah! Not only a warning, but an error, of course. I'll fix it immediately. Thanks for the report. (eike1[ab].pas)

&<---------- (snip) ----------- program fail;

type TFoo = 2.7 .. 2.8;

var MyFoo: TFoo;

begin MyFoo := 1.0; WriteLn (MyFoo) end. &<---------- (snap) -----------

Frank

CBFalconer wrote:

Eike Lange wrote:

...

The following program compiles correctly (shouldn't there a warning?).

&<---------- (snip) ----------- program fail;

type TFoo = 2.7 .. 2.8;

var MyFoo: TFoo;

begin MyFoo := 1.0; WriteLn (MyFoo) end. &<---------- (snap) -----------

Notice, that you need spaces arround ".." to disable warning messages: "fail.pas:4: Only one decimal point in real number allowed"

My GPC version is: Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/specs gpc version 20010924, based on 2.95.2 19991024 (release)

That sounds like a lexical scanner failing. The real number parser should treat any second decimal point as a terminator character. Once any decimal point has been read the only non-numerics allowed should be 'e' and 'E', possibly immediately followed by '+' or '-'.

Yes, but since the program is wrong, anyway (subranges of Real are not allowed), the lexer bug doesn't matter here.

But, indeed, there is a case where the problem does occur, but (AFAICS) only a very special case, using the old-style `(. .)' notation instead of `[ ]':

var a: array [Boolean] of ... r: Real;

begin ... a (.r > 2.0.) end

So I've fixed the lexer bug (it was as easy as you described).

Is the same failing in the run-time? i.e. what does "read(r);" do on such inputs?

It's correct (the following test program is only to make sure it won't break in the future :-).

program Chuck3 (Output);

var t: Text; r: Real; s: String (20);

begin Rewrite (t); WriteLn (t, '2.5..2.8'); Reset (t); ReadLn (t, r, s); if (r = 2.5) and (s = '..2.8') then WriteLn ('OK') else WriteLn ('failed') end.

Frank