Waldek Hebisch wrote:
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.
Here I disagree strongly. Untyped pointers are really dangerous, whereas typed pointers are not really type unsafe. They don't follow the strict standard Pascal rules, but only to an extent that is still safe, because the types are still structurally equivalent, so nothing dangerous can really happen. (I'm not talking about dangling pointers here -- these are irrelevant here, and can happen just the same in standard Pascal with danymic allocation.) Of course, BP has other dangerous constructs, but I see no reason to extend the danger unnecessarily.
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
More precisely, if both involved types are primitive. If one is and the other isn't, we proceed with structural matching, right?
(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.
Indeed, this could be a good solution for both problems. In BP mode (more precisely, in {$T+} mode -- thanks, Chief, for pointing out this fine point I wasn't aware of), all pointer types would be "unbranded". In default mode, explcit pointer types would be branded, but the result of @ would not (so, due to the rule above, it would be compatible with p1 and to p2, but p1 and p2 wouldn't be compatible with each other -- seems kind of sensible, perhaps that's also how Mac Pascal behaves?).
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.
Experience shows that this is more a theoretical possibility. :-(
Alternatively, a simple script should be enough to mark then as unfixed on a web page.
Good idea. I should try this.
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 see. (Though in this case, did someone actually write fixed-bug entries for the bug-list?)
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.
Sure. But actually I spend as much time working on GPC as I can afford, and I assume the same goes for you. So it would just be a question of fixing one bug vs. another one, and which one will affect users more seriously later is hard to predict. Of course, I agree that not fixing bugs is not good, but I doubt whether any administration effort will make a big difference.
But point taken, the bug list should be current. That is why I wrote about updating (maintaining) bug list.
I try not to lose bugs, often just by keeping relevant mails around, but I don't always get to writing a proper entry in the bug list -- which is not as trivial as it sounds, as many of the discussions are not clear bug-reports, but often a mixture of proper bugs, questions, unexpected though correct behaviour, and wishlist items, and sorting this out, and (for the latter cases) deciding what to do actually, is more work and sometimes requires further discussion. In fact, not seldom the discussion process takes much longer than the actual implementation after something was decided upon. And during the discussion, what should actually be put in the bug list? Only the minimally necessary (here, EP uncompliant type-checking in a particular case), or a vague description of the real issue ("better type-checking rules for various cases") ...
Frank