Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.unix.programmer,comp.lang.c Subject: Re: Odd compiler behaviour? Date: Wed, 02 Mar 2016 13:34:59 -0800 Organization: None to speak of Lines: 79 Message-ID: References: <20160301061135.783@kylheku.com> <87h9gqb0lj.fsf@mantic.terraraq.uk> <878u22aua9.fsf@mantic.terraraq.uk> <87wpplaojy.fsf@mantic.terraraq.uk> <87povdajp6.fsf@mantic.terraraq.uk> <871t7sam40.fsf@mantic.terraraq.uk> <87si0894om.fsf@mantic.terraraq.uk> <87mvqg92q1.fsf@mantic.terraraq.uk> <87egbs904a.fsf@mantic.terraraq.uk> <8760x48x2b.fsf@mantic.terraraq.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="9850"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+echQ2gvTc64BgQpcaY2Qo" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:N0D3ruOln/M+L6uCjHGZFiWpdBU= sha1:Sb6dMJOU/6Vi+RK3DnR7rWMhIAs= Xref: csiph.com comp.unix.programmer:8020 comp.lang.c:83033 Richard Kettlewell writes: > Keith Thompson writes: >> Richard Kettlewell writes: >>> Keith Thompson writes: >>>> Richard Kettlewell writes: >>>>> Barry Margolin writes: >>>>>> I was making a very broad generalization: the C language is designed to >>>>>> make it easy for the compiler to translate basic operations >>>>>> straightforwardly into simple machine codes. >>>>> >>>>> Unfortunately it was an inaccurate and misleading generalization. >>>> >>>> I disagree. I think it's an accurate generalization. >>>> >>>> As a simple example, given: >>>> >>>> int n; >>>> /* ... */ >>>> n ++; >>>> >>>> a compiler must generate code that increments n if n's value is less >>>> than INT_MAX, but has no requirements if n == INT_MAX (the behavior is >>>> undefined). >>> >>> That’s the opposite of Barry’s generalization. I don’t see how a >>> counterexample to a proposition can support the argument that it’s an >>> accurate generalization. >> >> What? >> >> You snipped this statement: >> >> | A major purpose of leaving the behavior of INT_MAX + 1 undefined is to >> | permit `n ++` to be implemented as a simple increment instruction. >> >> which supports Barry's "generalization". > > It doesn’t matter what the purpose is. If we’re making statements about > the semantics of C programs, what that matters is the requirements in > the language specification. Both matter. Barry's comment was about the rationale behind the requirements. I find it useful to understand why the requirements are as they are. If you don't care about the purpose, that's fine -- but you said that Barry's comment was incorrect, not that it's irrelevant. >> The fact that, in this case, INT_MAX+1 has undefined behavior *permits* >> compilers to generate simple straightforward code. It also permits >> compilers to do arbitrarily fancy things to handle the exceptional case >> where n==INT_MAX. > > The last sentence is the bit that contradicts the generalization. It > does indeed permit the use of a simple increment instruction, but it > also permits *any other outcome* for the n==INT_MAX case. > > “This International Standard imposes no requirements” doesn’t mean “do > the fastest thing” or “use the most convenient CPU instruction”, or > anything else like that. It just means no requirements. Of course I'm perfectly well aware of all that. Again, here's Barry's remark: >>>>>> I was making a very broad generalization: the C language is designed to >>>>>> make it easy for the compiler to translate basic operations >>>>>> straightforwardly into simple machine codes. If his statement included the word "only" after "designed", I would understand and agree with your objection. I think he's merely saying (and I agree) that the ability to generate straightforward machine code is *one* of the reasons for the current design. -- 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"