🚀 go-pugleaf

In article <10279@goanna.cs.rmit.oz.au> ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
>In article <1611@imec.UUCP> donne@imec.be (Werner Donne) wrote:
>> Why is the assignment illegal?
>In article <1992Apr15.014523.5364@cs.mcgill.ca>,
>storm@cs.mcgill.ca (Marc WANDSCHNEIDER) replied:
>> As far as I can see, it isn't.  I ran it on cc for the NeXTs, gcc
>> running under SunOS 4.1.1 and as well, on MSC and Borland C++ 3.0 on my
>> PC in front of me...  Not one compiler even complained about the assignment.

[Digital's e-mail regulations prohibit an honest response to that.  -- N.D.
 Disclaimer:  The low flame level here does not reflect my personal opinion.]

>Encore Multimax running their version of 4.3BSD:
>% cat foo.c
>int main(void) { const char **a; char **b; a = b; return 0; }
>% gcc -ansi -pedantic foo.c
>foo.c: In function main:
>foo.c:1: warning: assignment between incompatible pointer types
>
>Quite right too.

[Disclaimer:  The remainder of this response does not reflect my employer's
policies.  -- N.D.]

Yes, by the ANSI/ISO C standard, it is right.  I think that Mr. Donne was
not asking if his assignment is illegal though.  He was asking WHY it's
illegal.  I've seen postings by committee members agreeing that that kind
of assignment was reasonable, regretting that they had not found a better
requirement, and saying that the REASON was because it would take too much
effort for them to find wording for a better requirement.

>The handling of read/write modifiers on pointers was pretty well worked
>out in Mark Rain's "MARY" language, so there was relevant (MARY was an
>Algol-68-derivative for systems programming) prior art.

Now, Mr. O'Keefe, I am surprised.  Do you mean that you further considered
the error message to be right on purely logical grounds, about what would
make a program unsafe?

Suppose the assignment of b to a were allowed, or suppose that a cast is
coded so that the assignment will occur.  The programmer can modify a again
later, but that's always expected for non-constant variables.  The programmer
can modify *a later, but the programmer could always modify *b anyway, so
there is no violation and no loss of reliability.  The programmer cannot
modify **a, so this cannot cause any problems or surprises.

Of course, a hypothetical assignment of a to b, which is also prohibited,
is quite rightly prohibited, so that a loss of reliability here would require
deliberate effort.  A programmer could get around that too by coding a cast,
and thus might[*] be able to modify an object that is supposed to be const.

[* If the actual object was not defined with the const qualifier, then such
a modification is permitted by the standard and has to work.  If the actual
object was defined with the const qualifier, then the result is undefined,
and might work anyway or might
ERROR FORMATTING HARD DISK - (A)bort, (R)etry, (I)gnore ?
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"Yeah -- bad wiring.  That was probably it.  Very bad."