[TUHS] : C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)
Dan Cross
crossd at gmail.com
Tue Mar 14 06:26:54 AEST 2023
On Mon, Mar 13, 2023 at 3:16 PM Steve Nickolas <usotsuki at buric.co> 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: <stdint.h>
>
> Beyond that, I still code strict C89. I simply treat the language itself
> as ossified. I also still make assumptions about the compiler that might
> not still be true, so for example
>
> unsigned short a;
> unsigned char b;
>
> b=0xFF;
> a=b<<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.
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=0xFF;
> a=b;
> a<<=8;
Curiously, this will be subject to the same type promotion rules as
the original.
> or alternatively
>
> b=0xFF;
> a=((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 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; 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."
- Dan C.
More information about the TUHS
mailing list