Const conflict. Was: Re: New Alpha_(re)

Thu, 24 Apr 1997 14:20:00 +0200

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).
-- 
Frank Heckenbach, Erlangen, Germany
heckenb@mi.uni-erlangen.de
Turbo Pascal:   http://www.mi.uni-erlangen.de/~heckenb/programs.htm
Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

Frank Heckenbach (heckenb@mi.uni-erlangen.de)