According to Frank Heckenbach:
[...] However, the following still doesn't work (if it's already/still on the bug list, please ignore):
PROGRAM x; CONST n:1..16=6; {"subrange bounds are not of the same type"} BEGIN END.
Is this really a bug??? Extended Pascal allows expressions as the upper bound of a subrange. In this case, the expresson "16 = 6" (with the Boolean value "false") is the upper bound - which is indeed not of the same type as the lower bound "1".
This is a known shift/reduce conflict in the parser. In principle it should be possible to tell bison to shift it rather than to reduce it - just like with the "dangling else" problem. Since I am a complete beginner with parsers (no theoretical knowledge; my only experience with bison relates to GPC) I would be glad if somebody could help me with this.
{The same with "var ...=...", ok with "var ... value ..."}
Strange. On my box, it works with `value'.
Then, a very small problem:
I have a Pascal program (let's say foo.pas) that uses some units. [...] If I compile it with "gpc foo.pas bar.c", it works fine. But if I do "gpc bar.c foo.pas", it doesn't ("Undefined references" to the C functions).
I think that's intended: The GNU linker is a one-pass linker which needs the "lowest" unit in the most right position of the command line. (I think. I don't really know.;-)
In the latter situation also the file foo.gpc is left.
That's indeed a bug. Thanks for the report.
Greetings,
Peter
Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125]