Help me cast this!: Ultrix 2.x bug

[Tom Karzes]

In article <52684 at sun.uucp> guy at gorodish.Sun.COM (Guy Harris) writes:
>First: mail to "root" at "mfci" failed, so I'll post this; could the person
>maintaining netnews at Multiflow please try to arrange that not all messages
>from there have a "From:" line listing "root at mfci.UUCP" as the poster?  The
>*real* poster's name appears in the "Reply-To:" line, so the information *is*
>available.

Unfortunately, no one here is responsible for maintaining netnews.  However,
the problem is that the From field isn't being set by the machine on which
the message originates, so it ends up being set to root.  In theory this
won't happen if the From field is set manually.  If I ever have the time I'll
probably fix it, but until then we'll see if this works.

>This is *not* the same as the "it" referred to above, which is an assignment
>of a value of type "struct outfile **" to a variable of type
>"struct outfile (*)[]".  The latter is not valid; "array of <type>" and
>"pointer to <type>" are inequivalent types, and therefore "pointer to array
>of <type>" and "pointer to pointer to <type>" are inequivalent types.  I would
>be *EXTREMELY* surprised if Dennis Ritchie felt they were equivalent.

This is a slight oversimplification.  In many contexts, "array of <type>"
will be converted to "pointer to <type>", so that things like the following
are legal:

    int     a[10];
    int    *p;

    p = a;

The types "int *" and "int [10]" are inequivalent, but in the above context
"int [10]" is coerced to "int *".  The point of contention is whether similar
coercion should take place at deeper levels, as in:

    int   (*p)[10];
    int   **q;

    p = q;

This is obviously bad because p requires one level of physical indirection
while q requires two levels of physical indirection, although both contain
two levels of "virtual" indirection.  I don't like it any more than you
or Chris do, and if it were up to me I'd make it illegal.  The only
reasons I can cite for considering it legal C are as follows:

    1.  Code such as this has historically compiled without warning in
        pcc-derived compilers, which inevitably leads to people using
        (type **) as a cast where they should really use (type (*)[N]),
        because they didn't know the correct way to form the cast.

    2.  Bjarne once told me that Dennis told him that this was C.  I have
        no knowledge of this other than what I sent in my previous posting.

In spite of this, I still think it's probably worth giving a warning,
since it's most likely a bug if someone writes such code.  If it's not
a bug, then they either used the wrong cast or were just lazy.

>If it's not clear why they must be inequivalent, here's a specific example.
[deleted example]

Yes, it's clear why they should be incompatible types.  It always has been.