On Tue, Jun 28, 2005 at 04:03:49PM +0100, Andrew Haley wrote: > Olivier Galibert writes: > > On Tue, Jun 28, 2005 at 03:39:38PM +0100, Dave Korn wrote: > > > ----Original Message---- > > > >From: Olivier Galibert > > > >Sent: 28 June 2005 15:25 > > > > > > > In particular, a very large number of C and C++ programs are written > > > > with the assumptions: > > > > > > This is a bad line of reasoning in general. There is a vast amount of > bad > > > software in the world, some blatantly buggy, some subtly-incorrect. To > > > attempt to fix it all in the compiler rather than the source seems a bit > > > bass-ackwards to me! > > > > Welcome to the real world. Useful compilers are not an exercise in > > theorical computing, especially for languages like C or C++. > > This is childish and insulting.
Calling a large part of the programs out there, including a non negligible subpart of what I personally write either "blatantly buggy" or "subtly-incorrect" is somewhat childish and insulting. > The standard of discourse on this list has been dropping of late, and > we'd all get a lot more done if we'd learn to take a deep breath > before posting. Try to remember this is a technical discussion, not > an argument in a bar. Lemme give the long version then. C has been created as a system programming language[1], and is still _the_ system programming language. Its types are by design very dependant on the real hardware, and even its behaviour. And the standardization, probably to the great chagrin of language theorists, has been careful to reflect that, leaving large areas underspecified to allow both the compiler and the programmer to rely on the appropriate hardware-defined behaviour where useful. Knowing what you run on is not being subtly incorrect, it's being an engineer instead of a theorist. Languages which try to define every behaviour independently of the hardware either run on virtual machines or require the help of Hossein Rezazadeh to move the specs around. Now, given this hardware dependance of the language on one side and a desire for reasonable portability on the other there pretty much exists classes of hardware a given program will compile and run on. Only theorical, and essentially uninteresting, programs will run on everything. The main class today is the one I was talking about: - 8 bits char, 16 bits short, 32 bits int, 64 bits long long - 2-complement without surprises, with the exception that overflow on loop induction variables is essentially always a bug - long is the same size as pointer (intptr_t is not very accepted yet), pointer to function and pointer to data have the same size - 32 and 64 bits ieee for float and double - null pointer is all bits 0 - volatile means something can modify the value at any time - memory is naturally byte-accessible, you just have to be careful with alignments (and even then it's often considered that the OS should provide transparent unaligned accesses if the hardware doesn't do it by itself) And probably some others I'm forgetting. Thinking that programs which rely on these assumptions are incorrect is the attitude of a theorist with his head in the sand. The kind of people that should never be left anywhere near the source of a C compiler. And to break themyou need a really, compelling hardware reason. Breaking sizeof(void *) == sizeof(int) took years for people and programs to adapt and is still not completely there yet. Breaking aliasing took a while too. Even embedded hardware tend to converge on that class for flexibility and interoperability reasons. Those who aren't there yet keep a very, very close control on their software environment and don't plan to run anything they find on sourceforge without a large amount of effort. And they use the C compiler even more as a high-level assembler than most people. Anyway, my point is that breaking these assumptions just because the standard does not specify them is silly. They're driven by the hardware, not by the wishes of compiler writers or of language theorists. OG. [1] http://cm.bell-labs.com/cm/cs/who/dmr/chist.html
