On Tue, Jun 28, 2005 at 06:36:26PM +0100, Dave Korn wrote: > It certainly wasn't meant to be. It was meant to be a dispassionate > description of the state of facts. Software that violates the C standard > just *is* "buggy" or "incorrect", and your personal pride has absolutely > nothing to do with it.
Then your definition of "incorrect" is uninteresting. Per your definition, "use of implementation-defined behaviour is incorrect", essentially no non-trivial program is correct. Including gcc for a start, which can't be correct, ever. > If you re-read what *you* originally said, you made it look like you were > talking in abstract terms about software-in-general, I said "A very large number of C and C++ programs". That includes kernels, gnome, kde, lots of things. Or if you want programs I work(ed) on, xemacs and mame. > and that's certainly > what I was referring to when I replied; it's unreasonable of you to point at > that very generalised sentence and suddenly say "I was talking about my own > code, even though I hid the fact, and so you've insulted me by disparaging > it". You disparaged probably around 99% of a typical linux distribution. Find one non-trivial program that doesn't assume that int is 32 bits. Find one of *your* programs that doesn't. > No number of correct assumptions about the sizes of various types or the > representation of NULL pointers will validate the incorrect assumption that > signed integer arithmetic could be made to wrap without obliging the > compiler to emit lousy code and miss an awful lot of loop-optimisation > opportunities. Sure, and you'll notice I always special-cased the loop induction variables. Maybe you should reread what I was replying to: On Tue, Jun 28, 2005 at 08:57:20AM -0400, Robert Dewar wrote: > But the whole idea of hardware semantics is bogus, since you are > assuming some connection between C and the hardware which does not > exist. C is not an assembly language. That is what I utterly disagree with. OG.
