From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 3274 invoked from network); 13 Mar 2023 22:26:02 -0000 Received: from minnie.tuhs.org (2600:3c01:e000:146::1) by inbox.vuxu.org with ESMTPUTF8; 13 Mar 2023 22:26:02 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 82FBD415F8; Tue, 14 Mar 2023 08:25:57 +1000 (AEST) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) by minnie.tuhs.org (Postfix) with ESMTPS id BE0B1415F5 for ; Tue, 14 Mar 2023 08:25:49 +1000 (AEST) Received: by mail-pf1-x434.google.com with SMTP id y33so220954pfa.5 for ; Mon, 13 Mar 2023 15:25:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678746349; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=MtdLrg642M0D+iEMiZvj6e7lK45rjl2lanZoXzsAZ8E=; b=iRud58nM9vpZm0UToBaZgxRTMkb5GaXeEu43OLzDIBGSJCLpChos34zH4jwP+NQKep mlybnw+eBReyq2/R446VpDPsR1RWjHVwW433FiP/umhN3KMs6nro1r4TF8m0r5rTKKwr jJvpJaGWqZEbvV0xWDi/zPuv4YVBm+NVlDLNzR7M9Nu+0m6YLd5oA09QPy4M6CPg1X4x 168EZoF7A9YDjaNFqj0Bvi+tZdpmDgh7tpsMU/El15bpFmfzh9gnjgvGbo4xXMf5QDTf knB4+3UnsHbr8+RUpCU8+e7S8shEVi0JN8R/a3aBydp5QOjTxygW5k6qqUPijo1y545O ZXdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678746349; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=MtdLrg642M0D+iEMiZvj6e7lK45rjl2lanZoXzsAZ8E=; b=uKfWx9aKGxouEqsNVyMBXIopMvwEAQ8v5GY9qFhnUCq6dtU+lQxFoEYJNDmRzUNEnk CPBtXHLhVIvj+U5zRrVFgtaFpm8j7z6iYH6C3ZDs4v+30E93V81SOzwqpqat7SG5h1kZ sqeTQP/+naTfuh1fjPzqSMaDONaYNF2gBNjqapJ5BwLAdv/i7JYcnjS6JYx2N+P5dTtD uz9ffCoTcwSpLH9lHXul//oOSrOeBmg5HSO1FiPV6lCI1HsT16QLA8xi/u+VowqWpFBq q0ZNIoQic/hZWfvkKWsioNp4txkOm8m/THGxB4BWLnOeu0ifA5PCzzoG7dPuz6vIZNVV qDnA== X-Gm-Message-State: AO0yUKXrOB5TyB0jw8BM3xvfXPynsWVsW3Rvd9cj9WCeJ0lrbpMjgnxu Wqlc3p6t5qqDHBcxx7uAaOFny5ztPqQdsy2SGdadpXBk X-Google-Smtp-Source: AK7set/nXiWPtW9FZtkl7l9RwMbJyl+DSrtDaP6AlU4Ah2KBQOlGATFaqQ/tJq2lKJzRCUa8MEI0VDLHxaeDEFt5aGc= X-Received: by 2002:a63:2950:0:b0:4fd:5105:eb93 with SMTP id bu16-20020a632950000000b004fd5105eb93mr11828123pgb.3.1678746348849; Mon, 13 Mar 2023 15:25:48 -0700 (PDT) MIME-Version: 1.0 References: <20230310113708.AD55518C080@mercury.lcs.mit.edu> In-Reply-To: From: "Alejandro Colomar (man-pages)" Date: Mon, 13 Mar 2023 23:25:37 +0100 Message-ID: To: Dan Cross Content-Type: multipart/alternative; boundary="000000000000ca8d6605f6cf97c7" Message-ID-Hash: XO3IHU42OO2ZXBKCM5NNMFSTEJV3ZGEH X-Message-ID-Hash: XO3IHU42OO2ZXBKCM5NNMFSTEJV3ZGEH X-MailFrom: alx.mailinglists@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: TUHS X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary) List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000ca8d6605f6cf97c7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 13, 2023, 21:27 Dan Cross wrote: > On Mon, Mar 13, 2023 at 3:16=E2=80=AFPM Steve Nickolas wrote: > > On Mon, 13 Mar 2023, Clem Cole wrote: > > > Frankly, I'd probably rather see ISO drop a bunch of the stuff they > are now > > > requiring and fall back at least to K&R2 -- keep it simple. The truth > is > > > that we still use the language today is that K&R2 C was then (and > still is) > > > good enough and got (gets) the job done extremely well. Overall, > I'm not > > > sure all the new "features" have added all that much. > > > > C99 did introduce one thing I use: > > > > Beyond that, I still code strict C89. I simply treat the language itse= lf > > as ossified. I also still make assumptions about the compiler that mig= ht > > not still be true, so for example > > > > unsigned short a; > > unsigned char b; > > > > b=3D0xFF; > > a=3Db<<8; > > > > I expect to return 0 even though the logical answer is 0xFF00, > > I don't know why one would expect that. `b` will be promoted to > (signed!!) `int` before the shift, and then the result of that > assigned to `a`, wrapping as needed to fit into the `unsigned short`; > on most reasonable systems the UB gods won't be angered. > C23 will be adding new types that don't have this issue (default promotion to in). If a variable has 3 bits, it will have 3 bits (until you mix it with a wider variable). Another whole class of Undefined Behavior (in ISO C) or implementation-defined behavior (K&R C) is 2's complement arithmetic which has never been portable, until C23. So it's not all bad. > OTOH, `uint16_t mul(uint16_t a, uint16_t b) { return a * b; }` is a UB > minefield on most systems. > > > and I > > _always_ code it like this: > > > > b=3D0xFF; > > a=3Db; > > a<<=3D8; > > Curiously, this will be subject to the same type promotion rules as > the original. > > > or alternatively > > > > b=3D0xFF; > > a=3D((unsigned short) b)<<8; > > As will this. In fact, the cast here is completely superfluous; the > shift will still be done using after promotion to signed int. > > > and there's other defensive stuff I do. I honestly don't see the point > in > > the other changes to the language and feel they take C away from what i= t > > has always been. > > I think an issue is that there is what people _think_ C does, and what > C _actually_ does, and the two are often discordant; Indeed. That's my feeling too. When discussing about features that programmers don't understand why they were added, it's rather often the case that the feature has been there for longer than they thought (if not since forever). this is why I > think you see people tweaking compiler options to create a dialect > that's reasonable to program in: given a large-enough code base, you > inevitably end up with a very peculiar dialect, which compounds the > problem. For example, I'm quite sure that the C dialect that Linux > uses is not the same as the C that Windows uses, and so on. The > compiler writers now seem very much of the mind where you point this > out and they look at you and say, "tough." > Even "safe" Rust is having its share of Undefined Behavior. Let's see how they deal with it. > - Dan C. > --000000000000ca8d6605f6cf97c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Mar 13, 2023, 21:27 Dan Cross <crossd@gmail.com> wrote:
On Mon, Mar 13, 2023 at 3:16=E2=80=AFPM Steve Nickolas= <usotsuki@buric.co> wrote:
> On Mon, 13 Mar 2023, Clem Cole wrote:
> > Frankly, I'd probably rather see ISO drop a bunch of the stuf= f they are now
> > requiring and fall back at least to K&R2 -- keep it simple. T= he truth is
> > that we still use the language today is that K&R2 C was then = (and still is)
> > good enough and got (gets) the job done extremely well.=C2=A0 =C2= =A0 Overall, I'm not
> > sure all the new "features" have added all that much. >
> C99 did introduce one thing I use: <stdint.h>
>
> Beyond that, I still code strict C89.=C2=A0 I simply treat the languag= e itself
> as ossified.=C2=A0 I also still make assumptions about the compiler th= at might
> not still be true, so for example
>
>=C2=A0 =C2=A0unsigned short a;
>=C2=A0 =C2=A0unsigned char b;
>
>=C2=A0 =C2=A0b=3D0xFF;
>=C2=A0 =C2=A0a=3Db<<8;
>
> I expect to return 0 even though the logical answer is 0xFF00,

I don't know why one would expect that. `b` will be promoted to
(signed!!) `int` before the shift, and then the result of that
assigned to `a`, wrapping as needed to fit into the `unsigned short`;
on most reasonable systems the UB gods won't be angered.

C23 will be add= ing new types that don't have this issue (default promotion to in).=C2= =A0 If a variable has 3 bits, it will have 3 bits (until you mix it with a = wider variable).

Another= whole class of Undefined Behavior (in ISO C) or implementation-defined beh= avior (K&R C) is 2's complement arithmetic which has never been por= table, until C23.=C2=A0 So it's not all bad.

OTOH, `uint16_t mul(uint16_t a, uint16_t b) { return a * b; }` is a UB
minefield on most systems.

> and I
> _always_ code it like this:
>
>=C2=A0 =C2=A0b=3D0xFF;
>=C2=A0 =C2=A0a=3Db;
>=C2=A0 =C2=A0a<<=3D8;

Curiously, this will be subject to the same type promotion rules as
the original.

> or alternatively
>
>=C2=A0 =C2=A0b=3D0xFF;
>=C2=A0 =C2=A0a=3D((unsigned short) b)<<8;

As will this. In fact, the cast here is completely superfluous; the
shift will still be done using after promotion to signed int.

> and there's other defensive stuff I do.=C2=A0 I honestly don't= see the point in
> the other changes to the language and feel they take C away from what = it
> has always been.

I think an issue is that there is what people _think_ C does, and what
C _actually_ does, and the two are often discordant;

Indeed.=C2=A0 That's my= feeling too.=C2=A0 When discussing about features that programmers don'= ;t understand why they were added, it's rather often the case that the = feature has been there for longer than they thought (if not since forever).=

this is why I
think you see people tweaking compiler options to create a dialect
that's reasonable to program in: given a large-enough code base, you inevitably end up with a very peculiar dialect, which compounds the
problem. For example, I'm quite sure that the C dialect that Linux
uses is not the same as the C that Windows uses, and so on. The
compiler writers now seem very much of the mind where you point this
out and they look at you and say, "tough."
=

Even "safe" R= ust is having its share of Undefined Behavior.=C2=A0 Let's see how they= deal with it.

--000000000000ca8d6605f6cf97c7--