Hai,
after porting a few thousand lines I think I spotted the next bug.
take this simple program:
program err;
type pword = ^word; word = boolean;
var pw : pword;
begin new(pw); pw^ := true; end.
This is rejected by gpc with:
err.pas: In main program: err.pas:12: incompatible types in assignment
But if I swap the order of the pword and word type decl's all's swell. Ofcourse using woord (dutch for word) instead of word solves it too.
On Wed, 17 Apr 2002, Carel Fellinger wrote:
Hai,
after porting a few thousand lines I think I spotted the next bug.
take this simple program:
program err; type pword = ^word; word = boolean;
word is predeclared as unsigned 32 bit integer. Should gpc complain already here or warn and accept the redefinition and do the job? Ernst-Ludwig
var pw : pword; begin new(pw); pw^ := true; end.This is rejected by gpc with:
err.pas: In main program: err.pas:12: incompatible types in assignmentBut if I swap the order of the pword and word type decl's all's swell. Ofcourse using woord (dutch for word) instead of word solves it too.
-- groetjes, carel
At 09:35 18/04/2002 , vous avez écrit:
On Wed, 17 Apr 2002, Carel Fellinger wrote:
Hai,
after porting a few thousand lines I think I spotted the next bug.
take this simple program:
program err; type pword = ^word; word = boolean;word is predeclared as unsigned 32 bit integer. Should gpc complain already here or warn and accept the redefinition and do the job?
For Free Pascal, we came also accross that problem, and we decided that ^word should allways be first considered as a forward declaration that can be defined later in the same type block.
I don't remember if this is specified by the pascal language, but its at least compatible with BP and Delphi/Kylix.
After reconsidering it, I also think that this is a more logical approach.
Pierre Muller Institut Charles Sadron 6,rue Boussingault F 67083 STRASBOURG CEDEX (France) mailto:muller@ics.u-strasbg.fr Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99
Hello,
On Thu, 18 Apr 2002, Ernst-Ludwig Bohnen wrote:
On Wed, 17 Apr 2002, Carel Fellinger wrote:
Hai,
after porting a few thousand lines I think I spotted the next bug.
take this simple program:
program err; type pword = ^word; word = boolean;word is predeclared as unsigned 32 bit integer. Should gpc complain already here or warn and accept the redefinition and do the job? Ernst-Ludwig
As far as I got the ISO standard correct, the 'pword' definition should only be considered a foreward declaration of 'word' when 'word' is undefined and has a definition later in the same block. So the current behaviour of GPC seems rather consequent to me and I don't understand why all Barland's compilers and FPC process it the other way ;-(
Regards, Adam Naumowicz
-------------------------------------- WWW: http://math.uwb.edu.pl/~adamn/ --------------------------------------
Adam Naumowicz wrote:
Hello,
On Thu, 18 Apr 2002, Ernst-Ludwig Bohnen wrote:
On Wed, 17 Apr 2002, Carel Fellinger wrote:
Hai,
after porting a few thousand lines I think I spotted the next bug.
take this simple program:
program err;
type pword = ^word; word = boolean;
word is predeclared as unsigned 32 bit integer. Should gpc complain already here or warn and accept the redefinition and do the job? Ernst-Ludwig
As far as I got the ISO standard correct, the 'pword' definition should only be considered a foreward declaration of 'word' when 'word' is undefined and has a definition later in the same block. So the current behaviour of GPC seems rather consequent to me and I don't understand why all Barland's compilers and FPC process it the other way ;-(
This is not the current behaviour of gpc. See the following snippet
------------------------------------------------------------------------
program forw;
type foo = real;
function testI: boolean; type p = ^foo; foo = integer; var v : p; begin testI := SizeOf(v^) = SizeOf(integer); end;
function testR: boolean; type p = ^foo; var v : p; begin testR := SizeOf(v^) = SizeOf(real); end;
begin if testI and testR then writeln('OK') else writeln('failed'); end.
-----------------------------------------------------------------
In testI type foo in entering the block is real as in testR, and p is considered as forward since v^ is integer.
The problem seems special to the predeclared identifier "word"
Maurice
On Thu, Apr 18, 2002 at 10:42:23AM +0200, Adam Naumowicz wrote: ...
As far as I got the ISO standard correct, the 'pword' definition should only be considered a foreward declaration of 'word' when 'word' is undefined and has a definition later in the same block. So the current behaviour of GPC
Well, according to iso10206 and iso7185, section 6.2.2.5 in both:
6.2.2.5
When an identifier or label has a defining-point for region A and another identifier or label having the same spelling has a defining-point for some region B enclosed by A, then region B and all regions enclosed by B shall be excluded from the scope of the defining-point for region A.
To me this contradicts your `when .. is undefined', so I still think it's a bug.
Carel Fellinger wrote:
On Thu, Apr 18, 2002 at 10:42:23AM +0200, Adam Naumowicz wrote: ...
As far as I got the ISO standard correct, the 'pword' definition should only be considered a foreward declaration of 'word' when 'word' is undefined and has a definition later in the same block. So the current behaviour of GPC
Well, according to iso10206 and iso7185, section 6.2.2.5 in both:
6.2.2.5 When an identifier or label has a defining-point for region A and another identifier or label having the same spelling has a defining-point for some region B enclosed by A, then region B and all regions enclosed by B shall be excluded from the scope of the defining-point for region A.To me this contradicts your `when .. is undefined', so I still think it's a bug.
So the behavior of gpc for ordinary identifiers like "foo" in my previous snippet is standard conformant, and the different behavior for the special case of "word" is not.
Maurice
Maurice Lombardi wrote:
Carel Fellinger wrote:
On Thu, Apr 18, 2002 at 10:42:23AM +0200, Adam Naumowicz wrote: ...
As far as I got the ISO standard correct, the 'pword' definition should only be considered a foreward declaration of 'word' when 'word' is undefined and has a definition later in the same block. So the current behaviour of GPC
Well, according to iso10206 and iso7185, section 6.2.2.5 in both:
6.2.2.5 When an identifier or label has a defining-point for region A and another identifier or label having the same spelling has a defining-point for some region B enclosed by A, then region B and all regions enclosed by B shall be excluded from the scope of the defining-point for region A.To me this contradicts your `when .. is undefined', so I still think it's a bug.
So the behavior of gpc for ordinary identifiers like "foo" in my previous snippet is standard conformant, and the different behavior for the special case of "word" is not.
I agree. This indicates (to me) that the predefinition of word is not occurring in the encompassing block 0.
Adam Naumowicz wrote:
On Thu, 18 Apr 2002, Ernst-Ludwig Bohnen wrote:
On Wed, 17 Apr 2002, Carel Fellinger wrote:
after porting a few thousand lines I think I spotted the next bug.
take this simple program:
program err; type pword = ^word; word = boolean;word is predeclared as unsigned 32 bit integer. Should gpc complain already here or warn and accept the redefinition and do the job?
As far as I got the ISO standard correct, the 'pword' definition should only be considered a foreward declaration of 'word' when 'word' is undefined and has a definition later in the same block. So the current behaviour of GPC seems rather consequent to me and I don't understand why all Barland's compilers and FPC process it the other way ;-(
If you don't delay the definition you have a situation where the outer block can invalidate a perfectly correct inner block. In particular, word is not predefined or reserved in ISO7185, and I find no reference to it in ISO10206. Converting a valid program to invalid has to be anathema. So I think that, in this case, Borland and FPC have it right.
CBFalconer wrote:
Adam Naumowicz wrote:
On Thu, 18 Apr 2002, Ernst-Ludwig Bohnen wrote:
On Wed, 17 Apr 2002, Carel Fellinger wrote:
after porting a few thousand lines I think I spotted the next bug.
take this simple program:
program err; type pword = ^word; word = boolean;word is predeclared as unsigned 32 bit integer. Should gpc complain already here or warn and accept the redefinition and do the job?
As far as I got the ISO standard correct, the 'pword' definition should only be considered a foreward declaration of 'word' when 'word' is undefined and has a definition later in the same block. So the current behaviour of GPC seems rather consequent to me and I don't understand why all Barland's compilers and FPC process it the other way ;-(
If you don't delay the definition you have a situation where the outer block can invalidate a perfectly correct inner block. In particular, word is not predefined or reserved in ISO7185, and I find no reference to it in ISO10206. Converting a valid program to invalid has to be anathema.
I think that's the most important argument.
Anyway, it turned out to be a plain bug. As Maurice noted, GPC behaves correctly for most identifiers, and only `Word' (and a few more) cause the problem.
The special thing about these identifiers is that there are built-in aliases of them (here: `Cardinal'), and GPC identified them too early. So in fact, pword would be changed if you redeclared Cardinal instead of Word. Of course, that's even "wronger" than the original bug. I've fixed all this now. (carel2*.pas) Thanks to all for the report and analysis.
Frank
-
Adam Naumowicz -
Carel Fellinger -
CBFalconer -
Ernst-Ludwig Bohnen -
Frank Heckenbach -
Maurice Lombardi -
Pierre Muller