30 Sep
2024
30 Sep
'24
9:12 p.m.
Rob Pike wrote in
<CAKzdPgwJ7-_BWztOQKiB6h5a+OGwXtefsD47Fq+GDwGGF7N4UA(a)mail.gmail.com>:
|On Mon, Sep 30, 2024 at 2:56 AM Douglas McIlroy <
|douglas.mcilroy(a)dartmouth.edu> wrote:
|>>>> malloc(0) isn't undefined behaviour but implementation defined.
|>>>
|>>> In modern C there is no difference between those two concepts.
|>
|>> Can you explain more about your view
|>
|> There certainly is a difference, but in this case the practical
|> implications are the same: avoid malloc(0). malloc(0) lies at the \
|> high end
|> of a range of severity of concerns about implementation-definedness. \
|> At the
|> low end are things like the size of ints, which only affects applications
|> that may confront very large numbers. In the middle is the default
|> signedness of chars, which generally may be mitigated by explicit type
|> declarations.
|>
|> For the size of ints, C offers guardrails like INT_MAX. There is no test
|> to discern what an error return from malloc(0) means.
|>
|> Is there any other C construct that implementation-definedness renders
|> useless?
|Gradually the writers of optimizing compilers have leaned so hard on the
|implementation-defined and undefined behaviors that, while far from
|useless, C and C++ have become non-portable and dangerously insecure, as
|well as often very surprising to the point that the US government arguing
|against using them.
Never attribute to malice what can adequately be explained by
incompetence.
is the signature of Poul-Henning Kamp (whose email regarding that
cstr list (i did not yet have TM-74-1273-1 aka the C Reference
Manual as of 1974-01-15, thank you!) was forwarded by Warren).
Only propaganda left everywhere, including here, namely for Rust.
But your statement in particular reminds me of "Who's afraid of
a big bad optimizing compiler?" of LWN.net, from July 15, 2019.
It may be fun to read by some. (Offline, searching surely works.)
It ends with
Acknowledgments
We owe thanks to a surprisingly large number of compiler
writers and members of the C and C++ standards committees who
introduced us to some of the things a big bad optimizing
compiler can do,[.]
But i think those eh people there (that US government) surely have
been hammered with "memory-safe language" a thousand times, and
noone ever told them that even the eldest C can be used in a safe
way; on freebsd-hackers (PHK is an early FreeBSD committer) there
was one of their bikeshed threads around September 5th, after
several CVEs where fixed, and another long time major contributor
started a thread saying things like
|>|The real takeaway here is that C is no longer sufficient for writing
|>|high quality code in the 2020s. Everyone needs to adapt their tools.
which (also) i (not FreeBSD, only by heart, maybe) spoke against.
He was hailing Option<Box<Vec<u8>>> or Vec::with_capacity(262144)
as solutions to the CVEs. (Which, as far as i looked, had nothing
really to do with C as such; one "guilty" programmer said, as far
as i understood that, the same for "his CVE".)
Vectors and string "objects" with (optionally) checked index
access and such are uncomfortable, but easy to do, also with C,
and right from the start (i said).
(P.S.: i miss bit enumerations in C and C++, as compilers get
stricter and stricter (you cannot even enum1|enum2 without
warnings no more, in i think C23; without cast, of course), but
bit flags "can" only come in via preprocessor constants, and are
completely unchecked. And enum1|enum2 *i* often have, if some
subtype adds flags on top of a basic type, isn't that natural, no
support on that front. And cast-less "super class casts".
I had not downloaded cstr#108-the_c++_programming_language yet.)
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)