From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Ross Morgan-Linial" To: Marc Lehmann Cc: gcc@gcc.gnu.org Subject: Re: type based aliasing again Date: Sat, 18 Sep 1999 22:18:00 -0000 Message-id: <199909190517.WAA02846@jetcity.com> References: <199909180950.CAA05238@jetcity.com> <19990918151905.F1650@cerebro.laendle> X-SW-Source: 1999-09/msg00807.html Date sent: Sat, 18 Sep 1999 15:19:05 +0200 From: Marc Lehmann To: rmorgan@jetcity.com Subject: Re: type based aliasing again > On Sat, Sep 18, 1999 at 02:49:47AM -0700, Ross Morgan-Linial 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. From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Ross Morgan-Linial" To: Marc Lehmann Cc: gcc@gcc.gnu.org Subject: Re: type based aliasing again Date: Thu, 30 Sep 1999 18:02:00 -0000 Message-ID: <199909190517.WAA02846@jetcity.com> References: <199909180950.CAA05238@jetcity.com> <19990918151905.F1650@cerebro.laendle> X-SW-Source: 1999-09n/msg00807.html Message-ID: <19990930180200.ykB5ezCaDQpv0E_2RMEGlh0aHfmdFSTSF748GM1SwpA@z> Date sent: Sat, 18 Sep 1999 15:19:05 +0200 From: Marc Lehmann To: rmorgan@jetcity.com Subject: Re: type based aliasing again > On Sat, Sep 18, 1999 at 02:49:47AM -0700, Ross Morgan-Linial 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.