Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Text Files Date: Mon, 26 Feb 2018 14:40:30 -0800 Organization: None to speak of Lines: 47 Message-ID: References: <5a8459d1$0$707$14726298@news.sunsite.dk> <87o9kq8gh3.fsf@bsb.me.uk> <87a7wa8040.fsf@bsb.me.uk> <87y3jsz6fm.fsf@bsb.me.uk> <6flv8d9ii03eh280a1l8sia5a1eul0bsjs@4ax.com> <9990dccb-4af6-4d66-8a03-8842bd0f92a4@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="7fc1547110f49e550839d416a90ac99b"; logging-data="32398"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19CW1svGHbgDCPDPcT+0ZJs" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:/wydPg2WPspBbmhwEyDj/LMqxck= sha1:TjsrEA0X1v7VCrppNfS7eD4AjS0= Xref: csiph.com comp.lang.c:127105 supercat@casperkitty.com writes: > On Sunday, February 25, 2018 at 5:55:12 PM UTC-6, Keith Thompson wrote: >> supercat@casperkitty.com writes: >> > The notion that UB should encourage quality implementations to >> > behave in wackier fashion than IDB did not emerge until long after >> > the Committee had decided which actions to classify as UB versus >> > IDB. >> >> Nonsense. Nobody is talking about "encouraging" wacky behavior. >> The point is that UB *permits* arbitrary behavior, and IDB does not. >> That affects what I can safely do in code that's intended to be >> portable. > > Perhaps the term "wacky" was unnecessarily pejorative and I should have been > more precise: behaviors whose side-effects are undocumented, unbounded, > unpredictable, and unrelated to the action being performed or the underlying > platform's natural responses to such actions. My objection was to the word "encouraging". Undefined behavior means that the standard "imposes no requirements". That doesn't encourage (or discourage) anything. > An expression like "int1 > int2*int3;", where int1, int2, and int3 are all > "int" objects without a volatile qualifier, would have two natural effects > for any value of those objects: yield the value 0 to an enclosing expression, > or yield the value 1 likewise. Some implementations might document that > the expression may have other side-effects, and some platforms might document > that they perform integer multiplication in ways that can have other side- > effects. When neither condition applies, however, I don't think compiler > writers would be eager to process such an expression in ways that could > have undocumented, unbounded, and unpredictable side-effects if they didn't > perceive the Standard as encouraging such treatment. As you know, the behavior of overflow on signed integer multiplication is undefined. Compilers take advantage of that for optimization. I hardly think they need any encouragement from the standard to want to generate faster code. Compilers are also perfectly free to define the behavior of overflow on signed integer multiplication. Nothing in the standard discourages them from doing so. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"