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 16:20:51 -0700
Organization: None to speak of
Lines: 35
Message-ID: <ln4l7tdvos.fsf@kst-u.example.com>
References: <de7f6c95-d2a8-4f26-9416-f72305578c3b@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> <lnpnqhe5v6.fsf@kst-u.example.com> <VPylE.543550$uD1.407887@fx33.am4>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="77bd598ae72395ba0a7bd923a7887244"; logging-data="17451"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+q1OeLnfcErpgT/eVUY1Ps"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:IYulkD70oamp7jp4EgdlQRtjYVE= sha1:acnFpmYcFMLIF4kq5dSDykelJvs=
Xref: csiph.com comp.lang.c:142322

Bart <bc@freeuk.com> writes:
> On 23/03/2019 19:41, Keith Thompson wrote:
>> Bart <bc@freeuk.com> 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.

Do you accept the fact that the C standard says what it says?

> I might take the same generic algorithm, and port to a half a dozen 
> languages including C.
>
> Only in C is integer overflow considered such a big deal, that it causes 
> undefined behaviour. And only in C, would code that overflows be assumed 
> to never happen, allowing compilers to do unpredictable things.

Yes, we all know that you don't like a lot of things about C.

When you make incorrect statements about what C says, we try to
correct them.  When you express opinions about C, some of us don't
bother to reply, because there's really not much to say about it
(and some of us might even agree with you on some points).

-- 
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 */