Frank Heckenbach wrote:
Waldek Hebisch wrote:
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.
Address operator is really a foreign intrusion into Pascal (of course, we need it, but still). I find it acceptable to get untyped pointer from address operator. Another possibility (used in Modula-3) is two have two kind of types: one which uses structural equivalence, and another (called "branded" in Modula-3) which uses name (declaration) equivalence. More precisely, to check is types are compatible one recursively checks if structure matches, stopping on primitive or branded types (primitive types have their own rules, different branded types are incompatible).
Actually, structural equivalence is IMHO the only sensible choice for array slices -- otherwise one gets too many spurious type errors.
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.
Bug fixes have dates, so it is easy to notice that the fix is after last release. Alternatively, a simple script should be enough to mark then as unfixed on a web page.
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. :-)
Bug list is an important tool for fixing (or mitigating effects of) bugs. It already happened to me to debug twice the same bug. I am sure I forgot some reports. The others forget too (recent "GPC alpha" thread is a proof).
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.
More harmful is when the bugs are not fixed and users discover them only when trying software. But point taken, the bug list should be current. That is why I wrote about updating (maintaining) bug list.