[TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary)

[Dan Cross <crossd@gmail.com>]

On Mon, Mar 13, 2023 at 3:16 PM 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 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.