Re: PATCH: `__norestrict' type qualifier

[Jamie Lokier <egcs at tantalophile dot demon dot co dot uk>]

Mark Mitchell wrote:
> My recollection, although it's getting foggy at this point, was that
> we had come up with (gradually) a macro that allowed unsafe casts,
> must as your __norestrict qualifier would.  As I recall, this macro
> depended on the (documented) aspect of GCC's behavior whereby
> type-puns via a union are allowed.  The criticism of that macro was
> that it requires relying on GCC's behavior, rather than any standard
> compiler-independent behavior.

I recall it's not even documented properly, unless GCC's documentation
has been updated recently.  The documentation excerpt posted to the list
was picked at by me in language lawyer fashion, and I could _not_ see
how the union behaviour followed, and others agreed but felt I was being
picky.  To be honest I still don't properly understand this area of
GCC's implementation.

Somehow along that line we realised it is GCC implementation-specific
behaviour.

Since I thought the documentation was an explanation of changes due to
standard type-aliasing rules, if the documentation was clear I don't
think anyone would have realised it is GCC implementation-specific! :-)

[I'd write "implementation-defined" but see below...]

> Personally, were I the Linux folks, I would like the last alternative
> best; it uses a documented GCC-specific behavior (as does much of the
> rest of the kernel code), but is self-documenting, tidy, fast, and
> would allow other implementations of UNSAFE_CAST should other
> compilers be used in the future.

IMO the use of a macro is no better or worse than an attribute in the
Linux source.  That's not a big deal to me.  A disadvantage of
UNSAFE_CAST for applications is that the macro will compile on other
compilers, but silently generate bad code on the better ones.

I do think we should either (a) _define_ and document this GCC
implementation-defined behaviour precisely (so even I understand it), or
(b) leave GCC the freedom to optimise further in future.

Personally, were I the GCC folks, I would go for (b) because someone
might think of a good optimisation in future.  (a) seems to be in the
same category as RMS stating that empty loops will never be optimised
away...

-- Jamie