Peter Gerwinski wrote:

...

             {The same with "var ...=...", ok with "var ... value ..."}

Strange. On my box, it works with `value'.

Yes, I meant it's ok with "value". Perhaps I was unclear.

...

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.;-)

I don't think that's the problem. I tried invocing ld manually, and it worked whether bar.o was put before or after the Pascal .o's. However, I noticed that the "automade" unit's .o files were not passed to ld in the latter case:

In the first case, gpc issued "ld ... some.o units.o foo.o bar.o ...", in the latter case, it was just "ld ... bar.o foo.o ..." (where foo.o and bar.o were actually temp file names containing the compiled code from foo.pas and bar.c, of course).

So, probably this has got something to do with the left over .gpc file...

Jakob Heinemann wrote:

...

...

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

Sorry, I didn't see the other possible interpretation when I reported the problem.

Actually, BTW, there is a bug in BP - it doesn't even accept the following... ;-)

const x:false..(2=3)=false;

I Suppose Frank intended to have a specific value of a subrange as a constant, but really this is not a good code example, for making good use of constants in a program you should make an explicit type declaration, and though I have not tried it this should work:

Thanks for the hint, that's what I'm doing now. It solves the "bug".

Phil Nelson wrote:

By forcing the reduce then the construct "CONST N : false .. 1 = 1 = false;" produces a syntax error. But, you can still do this by "CONST N : false .. (1 = 1) = false;"; So I would say that you do want to force the reduce and make equals have to be parenthesized to get comparison.

I thought so, too, but then I realized that this might break some Extended Pascal code:

var n:false..1=2;

would be valid in EP, but cause an error with the above modification.

var n:false..false=false;

would declare "n:false..true" uninitialized in EP, but "n:false..false value false" with the modification. While it doesn't seem to do any harm that the variable is initialized, it would make a difference that the range is limited, and a statement like "n:=true" would fail (with some kind of range checking)...

Sure, such things are not likely to occur in any real program, but perhaps in some test suites (and if not, they might have to be added to the test suites to claim really 100.00000% compatibility some time)...

So, I guess, to remain compatible, the modification can be effective only with "--borland-pascal", or at least not with "--extended-pascal".

But I don't know if it's possible to modify the parsing rules depending on switches. If not, I suggest to leave it as it is, and to issue a warning whenever such a thing is encountered, regardless of the switches, since it can be avoided in any case, as was shown, by parentheses or by an explicit type declaration (perhaps the text of the warning should also contain the solutions to avoid confusing people (like me) who encounter it for the first time).