Waldek Hebisch wrote:
Peter N Lewis wrote:
Currently, this compiles, I would think it would give a type check error:
program peter112;
type p1 = ^MedInt; p2 = ^MedInt;
procedure doit( p: p1 ); begin end;
var p: p2; begin doit( p ); end.
Should p1 and p2 be parameter type compatible?
MWPascal complains of the type check on the parameter...?
I tried searching the docs for type compatibility, but did not find anything on the subject, perhaps I need to read the spec?
p1 and p2 are distinct types. Distinct pointer types in Pascal are always incompatible. However, gpc (incorrectly) treats poiters to the same type as compatible.
As I think I mentioned in a previous PM, this is BP compatible. While I'm not generally an uncritical fan of BP features ;-), this one seems necessary when we have an address operator (otherwise, what would be type of an address operator expression? It wouldn't be compatible with anything). Since we have the address operator in default mode, I think we need this behaviour by default as well. Of course, in strict ISO modes, it's wrong.
BTW, I see that Mac Pascal seems to have the address operator, so how does it behave actually, Peter? If foo is a MedInt, would @foo be compatible to a variable of type p1, p2, the parameter p, or what? Or compatible to any pointer type, i.e., @ returning an untyped pointer, like earlier BP verisons did (later ones had an option)?
This is a known problem, but requires some effort to fix. BTW, gpc bug list gets updated only when new releas appears, and then AFAICS only fixed bugs gets included. It seems that we need a "real" bug list. Frank, if you do not have time to update bug list in real time, maybe we should ask for a volunteer to maintain the list?
I see the problem. Actually, I do update *my* bug list in real time, but I also include bugs fixed in my development version, and publishing these as fixed (while the corresponding code has not been released, and often even while it still causes other regressions for me) would be misleading as well.
BTW, the bug list doesn't really claim to be complete. (It started with me collecting bug reports from the mailing list many years ago, and updating what I happened to notice.) And creating a comprehensive bug list has always been a lower priority to me than fixing some of the bugs. :-)
I wouldn't object to someone else maintaining a bug database, but I'd ask for one thing: To keep it current, especially WRT fixed bugs (so just the other emphasis than what Waldek asked for). I think nothing is more harmful to a project's reputation than a list of stale bugs which have actually long been fixed.
(We've been through that in GPC: For a long time, its documentation carried a test suite run on a system which was years old and many of the failures found were long fixed. More recently, I found a bug in the Debian database, which someone had entered there a few years ago. Matthias Klose had forwarded the report to us back then, and we fixed it, but it was forgotten in the database. After I discovered it, I "closed" it, of course, but as I do not regularly monitor the Debian bug database for gpc, and apparently noone else does either, this was done 2-3 years too late.)
Frank