Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <kst-u@mib.org>
Newsgroups: comp.lang.c
Subject: Re: C wish list
Date: Sat, 23 Mar 2019 13:51:44 -0700
Organization: None to speak of
Lines: 40
Message-ID: <lnh8bte2lb.fsf@kst-u.example.com>
References: <de7f6c95-d2a8-4f26-9416-f72305578c3b@googlegroups.com> <11b51bdf-7847-40fc-bdf5-b3777f41b4da@googlegroups.com> <q6ucr8$sc1$1@dont-email.me> <Q2zkE.172267$1p7.137601@fx05.am4> <q70jg2$ec1$1@z-news.wcss.wroc.pl> <18RkE.296542$DH4.255445@fx24.am4> <q70vsp$avo$1@dont-email.me> <i_TkE.658776$OGY.405413@fx08.am4> <q72dfr$1c0$1@dont-email.me> <GP3lE.407767$%B.175266@fx03.am4> <q72npb$qtv$1@dont-email.me> <Yt6lE.304038$7F3.192949@fx30.am4> <q72tse$fn$1@dont-email.me> <2J7lE.185089$1p7.119303@fx05.am4> <lnbm22g2ox.fsf@kst-u.example.com> <tzalE.538943$uD1.435519@fx33.am4> <ln36neg124.fsf@kst-u.example.com> <2PalE.135956$Ef4.37063@fx38.am4> <lny356eikx.fsf@kst-u.example.com> <4BqlE.730757$RBa.544247@fx15.am4> <q75kmv$6kv$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="4a6af93c7e45d7e76566eb7881bd7a1f"; logging-data="13994"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+WRvCDr6S+lJy/FvGFcRJ4"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:vKbrOa6d5b3QKNBbLmSWWAQlT28= sha1:WzXZ7AWZrtHzaK9UI8Psh6p14A8=
Xref: csiph.com comp.lang.c:142314

David Brown <david.brown@hesbynett.no> writes:
> On 23/03/2019 14:33, Bart wrote:
[...]
>> BC (me):
>>  >> You [DB] are saying that here:
>>  >>
>>  >>           int32_t x = f();
>>  >>           int32_t y = <some expression involving x, such as x>>8>
>>  >>
>>  >> it is acceptable to use a 64-bit version of x, even though x is only
>>  >> 32 bits, because it's using a value left over in a 64-bit register
>>  >> from some immediately prior calculation of x.
>
> Yes, when you have undefined behaviour!  Once you have written "int x
> = 1 << 31;", then /anything/ afterwards is allowed.  /Anything/.  The
> compiler can do whatever it wants.

David, I think you may have fallen into a trap (not necessarily
a deliberate one), and Bart has seized on it.  Bart's example,
reduced to actual code, is:

    int32_t x = f();
    int32_t y = x >> 8;

does *not* have undefined behavior (assuming f() is well defined).
It cannot produce a result that depends on, for example, the upper
half of some 64-bit register.

I think Bart is incorrectly assuming that it doesn't matter much
whether the code has undefined behavior or not.

I suggest waiting for Bart to post a clear example (with no
pseudo-code) that we can discuss meaningfully.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */