14 Mar
2023
14 Mar
'23
4:25 a.m.
On Mon, Mar 13, 2023, 21:27 Dan Cross <crossd(a)gmail.com> wrote:
On Mon, Mar 13, 2023 at 3:16 PM Steve Nickolas
<usotsuki(a)buric.co> wrote:
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.
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, OTOH, `uint16_t mul(uint16_t a, uint16_t b) { return a
* b; }` is a UB
minefield on most systems.
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
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; 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.
<https://github.com/rust-lang/rust/issues/107975>
- Dan C.