[TUHS] Re: Minimum Array Sizes in 16 bit C (was Maximum)

[Dan Cross <crossd@gmail.com>]

On Mon, Sep 30, 2024 at 4:22 PM Rik Farrow <rik@rikfarrow.com> wrote:
> This is the 'problem' with C/C++: it's not the language itself so much as the people who are allowed, or forced, to use it.

Programmer ability is certainly an issue, but I would suggest that
another goes back to what Rob was alluding to: compiler writers have
taken too much advantage of UB, making it difficult to write
well-formed programs that last.

The `realloc` function I mentioned earlier is a good case in point;
the first ANSI C standard says this: "If ptr is a null pointer, the
realloc function behaves like the malloc function for the specified
size. ... If size is zero and ptr is not a null pointer, the object it
points to is freed." While the description of `malloc` doesn't say
thing about what happens when `size` is 0, perhaps making `realloc(0,
NULL)` nominally UB (??), the behavior of `realloc(0, ptr)` is clearly
well defined when `ptr` is not nil, and it's entirely possible that
programs were written with that well-defined behavior as an
assumption. (Worth mentioning is that this language was changed in
C99, and implementations started differing from there.)

But now, C23 has made `realloc(0, ptr)` UB, regardless of the value of
`ptr`, and since compiler writers have given themselves license to
take an extremely broad view of what they can do if a program exhibits
UB, programs that were previously well-defined with respect to C90 may
well stop working properly when compiled with modern compilers.  I
don't think this is a hypothetical; C programs that appear to be
working as expected for years have, and will continue, to suddenly
break when compiled with a newer compiler, because the programmer
tripped a UB trigger somewhere along the way, likely without even
recognizing it. Moreover, I don't believe that there are any
non-trivial C programs out there that don't have such timebombs
lurking throughout. How could they not, if things that were previously
well-defined can become UB in subsequent revisions of the standard?

Perhaps I've mentioned it before, but a great example of the
surprising nature of UB is the following program:

    unsigned short mul(unsigned short a, unsigned short b) { return a * b; }

Is this tiny function always well-defined? Sadly, no, at least not on
most common platforms where `int` is 32 bits and `short` is 16. On
such platforms, the "usual arithmetic conversions" will kick in before
the multiplication, and the values will be converted to _signed_ ints
and _then_ multiplied; the product will then be converted back to
`unsigned short`. And while the type conversion process both ways is
well-defined, there exist values a,b of type unsigned short so that
a*b will overflow a signed 32-bit int (consider 0xffff*0xffff), and
signed integer overflow is UB; a compiler would be well within its
rights to assume that such overflow can never occur and generate, say,
a saturating multiplication instruction if it so chose. This would
work, be perfectly legal, and almost certainly be surprising to the
programmer.

The fix is simple, of course:

    unsigned short
    mul(unsigned short a, unsigned short b)
    {
        unsigned int aa = a, bb = b;
        return aa * bb;
    }

But one would have to know to write such a thing in the first place.

> Many, if not all, of the people on this list have worked with great programmers, when most programmers are average at best. I saw some terrible things back when doing technical sales support for a startup selling a graphics library with C bindings. I came away convinced that most of the 'programmers' I was training were truly clueless.

My sense is that tossing in bad programmers is just throwing gasoline
onto a dumpster fire. Particularly when they look to charlatans like
Robert Martin or Allen Holub as sources of education and inspiration
instead of seeking out proper sources of education.

        - Dan C.