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

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

Waldek Hebisch wrote:

Frank Heckenbach wrote:

...

Waldek Hebisch wrote:

...

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?

I do not remember the exact rules used by Modula-3. But reasonable rule is:

compatible (t1, t2) if t1 = t2 then return true; if branded(t1) or branded(t2) then return false; if composite(t1) and composite(t2) then return match_components(t1, t2) else return match_primitive(t1, t2);

Note that branded type is always incompatible with unbranded one. Otherwise it is too easy to break protection of branded types.

I hope this won't be too strict. (I can't think of a good example right now. I guess I'd have to test it on my code base when implemented ...)

Also, it is much nicer if compatibility is transitive.

True.

...

...

(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?).

I am affraid that I prefer branded pointer to be incopatible with unbranded one. Then we need branded pointers in ISO modes and unbranded otherwise.

Yes -- that's why I thought otherwise, then we could have branded pointers in default mode.

I find it rather confusing if using value stored in a variable wuld be forbidden by typing rules.

In some sense this also happens elsewhere -- e.g., an integer value stored in a real variable can't be used (from the variable) as integer anymore.

...

...

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?)

Since ATM you keep the bug list only you can give definite answer.

BTW, the bug list is a texi file of the GPC manual (todo.texi). You're welcome to add diffs to this file when you send me a patch. (I can easily handle overlapping diffs when I made some changes myself meanwhile.) I also try to make entries from relevant ChangeLog entries, but I think you didn't make these either in this case. And since you knew better than me what the actual problem (symptom and/or causes) were, as I hadn't tested on Solaris at that time, I didn't try to write anything on my own.

Frank

Phil Nelson wrote:

On Friday 30 September 2005 01:26 pm, Frank Heckenbach wrote:

...

BTW, the bug list is a texi file of the GPC manual (todo.texi). You're welcome to add diffs to this file when you send me a patch.

At one point in time I had a gnats database set up for GNU Pascal, but it never really got used. If it would get used, I can set it up again. It does add more overhead than just the texi file, but it does allow people to ask what happened to a previous bug report without bothering the list or any developer.

Not to disparage your effort, but setting up the database is one thing. Another thing is entering and updating the entries. And apparently, nobody would do that, at least back then, as you noticed. As far as I'm concerned, anything that adds more overhead is really counterproductive. So such a system would be worthwhile only if other people would volunteer to maintain the database (i.e., enter the existing bugs, take new reports and bugfix notes from the list, and check entries after new releases).

BTW, (I don't know gnats so well), does it have text export facilities? Just in case the database is later dropped again, so we're not stuck with the data locked in.

BTW, if setting up gnats is not much harder than installing a Debian package, we can probably also do it on our server. The technical facilities (bandwidth etc.) are available. I'm really more concerned about contibutors ...

Frank

Phil Nelson wrote:

Not a big deal if I don't do this ... I'm not pleading ... but if it were decided that it could be of use to people using and devloping GNU-Pascal I'd be willing to maintain the database and make sure people who needed to edit and close PR could do it. I'd rather not set it up and then have it sit with 1 or 2 bugs in it for serveral years like last time.

So I guess now is the time for volunteers to raise their fingers ...

Frank

In message 1128095816.5104.898152@goedel.fjf.gnu.de, Frank Heckenbach ih8mj@fjf.gnu.de writes

And creating a comprehensive bug list has always been a lower priority to me than fixing some of the bugs. :-)

Quite right too. Keep up the excellent work Frank. We do appreciate your efforts.

Peter N Lewis wrote:

At 17:56 +0200 30/9/05, Frank Heckenbach wrote:

...

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)?

@foo is equivalent to type Pointer, it's compatible with any pointer.

I see. Untyped, as BP with `{$T-}'. Bad ...

At 20:57 +0200 30/9/05, Frank Heckenbach wrote:

...

...

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 sounds like a good solution. One thought too, if "unbranded" was an attribute, it might be useful for cases where you wanted to actively allow looser type checking than normal without having to set a looser mode in generally,

Of course, we have local options ({$local gnu-pascal} ... {$endlocal}) already, so do we need an alternative way? (Though maybe it wouldn't be much effort to implement ...)

perhaps something like:

type CFTypeRef = ^UInt32 atttribute( unbranded ); CFArrayRef = ^UInt32; CFStringRef = ^UInt32;

Now CFArrayRef and CFStringRef are incompatible, but both are compatible with the generic CFTypeRef....

According to Waldek's proposal (which, as I wrote later, I can see the point of, and will support if it "survives" a practical test run), they wouldn't.

Also, that could open the way for supporting univ in a relatively safe mode by saying:

procedure doit( p: univ MyType )

marks p as unbranded MyType

I'm not sure whether that would really be loose enoguh for univ (which is perhaps better as requiring a pointer type and matching as an untyped pointer), but it might be a safer solution that fits in well with this.

I don't think it would, as unbranded would only mean "do structural equivalence", whereas `univ' would be compatible with any pointer type (or even more).

Frank