From mboxrd@z Thu Jan 1 00:00:00 1970 From: craig@jcb-sc.com To: davem@redhat.com Cc: craig@jcb-sc.com Subject: Re: Linux and aliasing? Date: Thu, 03 Jun 1999 20:06:00 -0000 Message-id: <19990604015713.18068.qmail@deer> References: <19990603131344.W375@perlsupport.com> <19990603104038Z.mitchell@codesourcery.com> <199906031824.LAA26672@pizda.davem.net> <19990603120733J.mitchell@codesourcery.com> <199906031924.MAA00337@pizda.davem.net> <199906031924.MAA00337@pizda.davem.net> X-SW-Source: 1999-06/msg00109.html >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) From mboxrd@z Thu Jan 1 00:00:00 1970 From: craig@jcb-sc.com To: davem@redhat.com Cc: craig@jcb-sc.com Subject: Re: Linux and aliasing? Date: Wed, 30 Jun 1999 15:43:00 -0000 Message-ID: <19990604015713.18068.qmail@deer> References: <19990603131344.W375@perlsupport.com> <19990603104038Z.mitchell@codesourcery.com> <199906031824.LAA26672@pizda.davem.net> <19990603120733J.mitchell@codesourcery.com> <199906031924.MAA00337@pizda.davem.net> X-SW-Source: 1999-06n/msg00109.html Message-ID: <19990630154300.uQiXWaxoFJ8q80tAs0-IAokWcbkdBulW2TzEKYM430g@z> >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)