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 11:40:59 -0800 Organization: None to speak of Lines: 50 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> 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="10467"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/DYYG+MR2WJ+T1dchkmDV3" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:tnL0k96q7Li/dgnGoaboY6wyy3Q= sha1:8SLNZT8Cte7AoJD6ENQ61MrgG5M= Xref: csiph.com comp.unix.programmer:8013 comp.lang.c:83021 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". 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. If the compiler generates a simple increment instruction and n happens to be INT_MAX, the `n ++` will *typically* set n to INT_MIN -- but if, for example, the hardware implements saturating or trapping arithmetic, it would set n to INT_MAX or trap, respectively. -- 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"