Re: Linux and aliasing?

[craig at jcb-sc dot com]

>Common sense should override whatever standards say, where feasible,
>and I argue that here it is indeed feasible.

Maybe it is -- I haven't looked into the issues in detail -- but,
generally, it is very hard to implement common sense *in the compiler
itself*.

For all I know, this problem is the result of C, or gcc, being
too permissive about allowing casts across pointers to different
types...in the sense that, if that sort of thing was simply
disallowed, then programmers wouldn't even *think* they "knew what
they were doing", because they'd be getting compile-time diagnostics,
which, as you point out, is what they *should* be getting if the
compiler isn't basically successfully reading the programmer's mind
and implementing his desires.

In particular, while it might make sense for *your* application
to have the compiler "automatically" disable (even localized)
aliasing when it sees certain "suspicious" constructs, how do we
know there won't be people who say "hey, *we* use those constructs,
but we use them *correctly*, and we don't want to lose the
performance those alias assumptions give us", either now or in
the future?  Why should *they* have to pay for their more-
conforming (to the compiler's growing expectations, anyway) usage
by modifying their code, or even their shell scripts?

I'm thinking, more and more, that there really needs to be a
`GNU C--' or similar language for embedded systems, operating
systems like Linux, and so on, because the C standard seems
to be evolving towards making C *more*, not less, of a HLL,
and I doubt gcc (and its maintainers) will be up to the task
of making it fit both needs while evolving to handle new
architectures (e.g. IA64) in an optimal way.

(Or, anyone up for writing a BLISS front end to gcc, along with a
C-to-BLISS converter to be run over, for example, the Linux sources?  ;-)

        tq vm, (burley)