Re: type based aliasing again

["Ross Morgan-Linial" <rmorgan@jetcity.com>]

Date sent:      	Sat, 18 Sep 1999 15:19:05 +0200
From:           	Marc Lehmann <pcg@opengroup.org>
To:             	rmorgan@jetcity.com
Subject:        	Re: type based aliasing again

> On Sat, Sep 18, 1999 at 02:49:47AM -0700, Ross Morgan-Linial <rmorgan@jetcity.com> wrote:
> >     alloc must ensure (in a machine-dependent way) that its return 
> >     value is suitable for conversion to a pointer to double; then the 
> >     _use_ of the function is portable.
> > 
> > That seems to imply that it's okay to use a pointer pointing to an 
> > object of different type as long as it's suitably aligned. Of course, 
> > I'm hardly an expert on K&R C.
> 
> Use yes (copy, cast), but not dereference. This only means you can
> (temporarily) cast a pointer into some other datatype (as supported by the
> language, e.g. a long), and after casting back you can dereference it. You
> can not, however, use the long (or a pointer to a different type) and
> dereference a different type using it.

Actually, the sentence I thought implied it was this one:

    The resulting pointer may cause addressing exceptions upon use if 
    the subject pointer does not refer to an object suitably aligned 
    in storage.

I don't see why the part about alignment would be there if _any_ use 
of a pointer to data of the wrong type was bad. Sorry I wasn't clear.

Another argument for guessing K&R allowed access though arbitary 
pointers is that there is no exception for char *, so if it wasn't 
allowed memcpy-type functions would be impossible.

However, I just noticed that appendix A, section 16 seems to 
disallow, or at least discourage, this (and also provides a good 
short name for using a mistyped pointer):

    Some difficulties arise only when dubious coding practices are 
    used. It is exceedingly unwise to write programs that depend on 
    any of these properties.
    ...
    Fields are assigned to words and characters to integers right-to-
    left on the PDP-11 and left-to-right on other machines. These 
    differences are invisible to isolated programs which do not 
    indulge in type punning (for example, by converting an int 
    pointer to a char pointer and inspecting the pointed-to storage), 
    but must be accounted for when conforming to extrnally-imposed 
    storage layouts.