From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier To: mark@codesourcery.com Cc: ak@muc.de, toon@moene.indiv.nluug.nl, law@cygnus.com, jbuck@Synopsys.COM, torvalds@transmeta.com, craig@jcb-sc.com, davem@redhat.com, chip@perlsupport.com, egcs@egcs.cygnus.com Subject: Re: Linux and aliasing? Date: Mon, 07 Jun 1999 02:36:00 -0000 Message-id: <19990607113526.A17782@pcep-jamie.cern.ch> References: <19990605152349.A1923@fred.muc.de> <19990605104107T.mitchell@codesourcery.com> <19990605214133.A15508@pcep-jamie.cern.ch> <19990605165713D.mitchell@codesourcery.com> <19990605165713D.mitchell@codesourcery.com> X-SW-Source: 1999-06/msg00249.html PgGGmark@codesourcery.com wrote: > Jamie> *(foo*)(void*)(&x) > > I intended this to be covered by my proposal. This would officially > be a "funny cast", and considered able to alias anything, provided > that x is a variable of an expression of the form a->b or a.b. Why the restriction on x? Things I've seen around, that are outside your proposal: - accessing an integer/float as a struct, to access individual parts. - vice versa to generate hash values / do vector operations. - accessing an integer array as different size integers for fast vector operatings (e.g. image processing). Image processing is a particular pain. As are optimised implementations of strlen, strcpy, memcpy etc. We could just tell people their code will work if the pointed-to entity happens to be a struct member. We could tell them to use a union like they're supposed to. But simply fixing a vector processing kernel to use unions won't guarantee correct code: all the callers must be changed to use the union representation too, because the image processing ops may get inlined. Hence the special char * exception so things like memcpy work I suppose. > Jamie> I bet there's still a fair bit of that around. In the > Jamie> modern world we've got *reinterpret_cast(&x), which > Jamie> is presumably treated specially w.r.t. aliases. > > No, it does not. The use of reinterpret_cast does not exempt a > standard-conforming program from the rules about using an lvalue of > the wrong type to access storage. I meant more along the lines of "what GCC does" than "what the standard says" on this. I realise this gives undefined behaviour standard-wise. Presumably reinterpret_cast this equivalent to one of your "funny casts"? have nice day, -- Jamie From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier To: mark@codesourcery.com Cc: ak@muc.de, toon@moene.indiv.nluug.nl, law@cygnus.com, jbuck@Synopsys.COM, torvalds@transmeta.com, craig@jcb-sc.com, davem@redhat.com, chip@perlsupport.com, egcs@egcs.cygnus.com Subject: Re: Linux and aliasing? Date: Wed, 30 Jun 1999 15:43:00 -0000 Message-ID: <19990607113526.A17782@pcep-jamie.cern.ch> References: <19990605152349.A1923@fred.muc.de> <19990605104107T.mitchell@codesourcery.com> <19990605214133.A15508@pcep-jamie.cern.ch> <19990605165713D.mitchell@codesourcery.com> X-SW-Source: 1999-06n/msg00249.html Message-ID: <19990630154300.oefb8dl5yM_JLoJNI_IUsuDVzQj5OAlVbBHldSCNlHY@z> PgGGmark@codesourcery.com wrote: > Jamie> *(foo*)(void*)(&x) > > I intended this to be covered by my proposal. This would officially > be a "funny cast", and considered able to alias anything, provided > that x is a variable of an expression of the form a->b or a.b. Why the restriction on x? Things I've seen around, that are outside your proposal: - accessing an integer/float as a struct, to access individual parts. - vice versa to generate hash values / do vector operations. - accessing an integer array as different size integers for fast vector operatings (e.g. image processing). Image processing is a particular pain. As are optimised implementations of strlen, strcpy, memcpy etc. We could just tell people their code will work if the pointed-to entity happens to be a struct member. We could tell them to use a union like they're supposed to. But simply fixing a vector processing kernel to use unions won't guarantee correct code: all the callers must be changed to use the union representation too, because the image processing ops may get inlined. Hence the special char * exception so things like memcpy work I suppose. > Jamie> I bet there's still a fair bit of that around. In the > Jamie> modern world we've got *reinterpret_cast(&x), which > Jamie> is presumably treated specially w.r.t. aliases. > > No, it does not. The use of reinterpret_cast does not exempt a > standard-conforming program from the rules about using an lvalue of > the wrong type to access storage. I meant more along the lines of "what GCC does" than "what the standard says" on this. I realise this gives undefined behaviour standard-wise. Presumably reinterpret_cast this equivalent to one of your "funny casts"? have nice day, -- Jamie