Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: C wish list Date: Sat, 23 Mar 2019 18:35:00 -0700 Organization: None to speak of Lines: 49 Message-ID: References: <18RkE.296542$DH4.255445@fx24.am4> <2J7lE.185089$1p7.119303@fx05.am4> <2PalE.135956$Ef4.37063@fx38.am4> <4BqlE.730757$RBa.544247@fx15.am4> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="77bd598ae72395ba0a7bd923a7887244"; logging-data="26791"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18+6T4K21czlRh6ptAX1+wu" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:UCmG4YSt6iGrNSbKoWFewmuDXDk= sha1:4J8daRO1qcA/Rqj8YOU9jfex2aI= Xref: csiph.com comp.lang.c:142328 Bart writes: > On 23/03/2019 23:20, Keith Thompson wrote: >> Bart writes: >>> On 23/03/2019 19:41, Keith Thompson wrote: >>>> Bart writes: >>>> In real life, though, compilers are not "sloppy" in the way >>>> you describe. They assume, because they are permitted to do so, >>>> that the code they're processing has defined behavior (including >>>> unspecified or implementation-defined). If the code violates >>>> that assumption, they compiler might generate code that violates >>>> your expectations -- though strictly speaking if you write code >>>> whose behavior is undefined, >>> >>> Again, this is C's definition of undefined behaviour. >> >> Yes, it is. And this is comp.lang.c, so that's the relevant definition. > > Well, so what? Don't C programs run on the same hardware as other > languages? If they don't see the need to make integer overflow UB, then > why does C? Languages that don't make signed integer overflow undefined behavior either run only on CPUs on which signed integer operations behave consistently, or they impose extra overhead with run-time checks. If you have a counterexample, please cite it. And if I describe to you what the C standard says, please don't take it as a personal affront. > You're taking a very narrow view here. C's UB, especially in cases such > as integer overflow that can be well-defined in hardware, can be a right > PITA. It can be well-defined on *some* hardware. And maybe -- *maybe* -- it would be reasonable to consider narrowing C's semantics in a future edition of the standard. Maybe all target systems are able to perform signed integer addition, subtraction, multiplication, and division and produce results that are consistent across all of them. I don't think either of us knows enough about real-world CPU architectures to know whether that's true or not. (I believe Java defines the semantics of signed arithmetic as the common 2's-complement wraparound, but Java isn't implemented for as many target systems as C is.) -- Keith Thompson (The_Other_Keith) kst-u@mib.org Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */