Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: James Kuyper <jameskuyper@alumni.caltech.edu>
Newsgroups: comp.lang.c
Subject: Re: Top 10 most common hard skills listed on resumes...
Date: Sun, 25 Aug 2024 10:50:10 -0400
Organization: A noiseless patient Spider
Lines: 45
Message-ID: <vafgb2$1to4v$2@dont-email.me>
References: <vab101$3er$1@reader1.panix.com>
 <vad7ns$1g27b$1@raubtier-asyl.eternal-september.org>
 <vad8lr$1fv5u$1@dont-email.me> <vaf7f0$k51$2@reader1.panix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 25 Aug 2024 16:50:11 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="5942cf64926b4076416eb83bfa781503";
	logging-data="2023583"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18RTikvVvuooelEHGJvBn/h5w9WySqXjx0="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:gstKVEkrrGBkXbHX7AVf8chIz3Q=
In-Reply-To: <vaf7f0$k51$2@reader1.panix.com>
Content-Language: en-US
Bytes: 3722

On 8/25/24 08:18, John Forkosh wrote:
> Bart <bc@freeuk.com> wrote:
....
> I recall C as originally characterized as a "portable assembly language",
> as opposed to a "higher level language". And I'd agree with that
> assessment, whereby I think you're barking up the wrong tree by trying
> to evaluate its merits/demerits vis-a-vis higher-level languages.
> Consider it with respect to its own objectives, instead.

C has been mischaracterized as a "portable assembly language", but that
has never been an accurate characterization. It has, from the very
beginning, been defined by the behavior that is supposed to result from
translating and executing the C code, not the assembly language that's
supposed to be produced by the translation process.
C is a high level language. It is a very low-level high-level language,
but it's not in any sense an assembler.

There's a famous bug that involved unconditionally derefencing a pointer
returned by malloc() before checking whether or not that pointer was
null. The people who wrote that bug knew that the assembly code which
they naively expected to be generated by translating their program would
be perfectly safe on the platform they were working on: a null pointer
pointed at a specific location in memory, and it was safe to access that
location.

But C is not defined as producing the assembly language they naively
expected it to produce. It's defined by the behavior of the resulting
code when executed. Dereferencing a null pointer has undefined behavior,
so the compiler just assumed that the fact that they were dereferencing
the pointer meant that they knew, for a fact, for reasons unknown to the
compiler itself, that the pointer would never be null. Therefore, the
compiler optimized away the code that was supposed to be executed if the
pointer was null.
This is a perfectly legal optimization - since the standard imposes no
requirements on the behavior of a program when the behavior is
undefined, nothing the program could do when the pointer was null could
be incorrect behavior. Furthermore, this optimization was not on by
default, it applied only if you turned it on explicitly, which the
developers had done. It's OK to write code with behavior that is not
defined by the standard, so long as some other document does define the
behavior. But you need to be very sure you know what behavior that other
document defined - this compiler defined the behavior as causing
optimizations based upon the assumption that the pointer was not null.