By: Ricardo B (ricardo.b.delete@this.xxxxx.xx), October 30, 2006 8:40 am
Room: Moderated Discussions
Gabriele Svelto (gabriele.svelto@gmail.com) on 10/30/06 wrote:
---------------------------
>I found another interesting reference in the C99 spec for the unary * operator:
>
>"Among the invalid values for dereferencing a pointer by the unary * operator are
>a null pointer, an address inappropriately aligned for the type of object pointed
>to, and the address of an object after the end of its lifetime."
As Jason mentioned in the links he provided, you can argue that in an architecture that supports unaligned accesses, like x86, there is no such thing as as "an address inappropriately aligned for the type of object pointed".
But then again, after your findings, it's pretty much a moot point.
>
>I know I may sound like a language lawyer however I've been bitten already a couple
>of times by strict aliasing rules when compiling with full optimizations on. At
>the time it took me a while to realize that GCC was doing his job and it was me
>who had broken the rules. C is versatile and powerful but we are used to a lot of
>unspecified behaviour which usually Just Works (tm) but which may break under some (unusual?) conditions.
I'm all for language lawyers.
Not so unusual: much C code will break when compiled with optimization.
---------------------------
>I found another interesting reference in the C99 spec for the unary * operator:
>
>"Among the invalid values for dereferencing a pointer by the unary * operator are
>a null pointer, an address inappropriately aligned for the type of object pointed
>to, and the address of an object after the end of its lifetime."
As Jason mentioned in the links he provided, you can argue that in an architecture that supports unaligned accesses, like x86, there is no such thing as as "an address inappropriately aligned for the type of object pointed".
But then again, after your findings, it's pretty much a moot point.
>
>I know I may sound like a language lawyer however I've been bitten already a couple
>of times by strict aliasing rules when compiling with full optimizations on. At
>the time it took me a while to realize that GCC was doing his job and it was me
>who had broken the rules. C is versatile and powerful but we are used to a lot of
>unspecified behaviour which usually Just Works (tm) but which may break under some (unusual?) conditions.
I'm all for language lawyers.
Not so unusual: much C code will break when compiled with optimization.