Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Tue, 3 Sep 2024 09:29:22 +0200
Organization: A noiseless patient Spider
Lines: 69
Message-ID: <vb6dsi$38fmb$1@dont-email.me>
References: <2024Aug30.161204@mips.complang.tuwien.ac.at>
 <memo.20240830164247.19028y@jgd.cix.co.uk> <vasruo$id3b$1@dont-email.me>
 <2024Aug30.195831@mips.complang.tuwien.ac.at> <vat5ap$jthk$2@dont-email.me>
 <vaunhb$vckc$1@dont-email.me> <vautmu$vr5r$1@dont-email.me>
 <2024Aug31.170347@mips.complang.tuwien.ac.at> <vavpnh$13tj0$2@dont-email.me>
 <vb2hir$1ju7q$1@dont-email.me> <8lcadjhnlcj5se1hrmo232viiccjk5alu4@4ax.com>
 <vb3k0m$1rth7$1@dont-email.me>
 <17d615c6a9e70e9fabe1721c55cfa176@www.novabbs.org>
 <86v7zep35n.fsf@linuxsc.com> <20240902180903.000035ee@yahoo.com>
 <86r0a2otte.fsf@linuxsc.com> <vb50cm$2uttr$1@dont-email.me>
 <vb58i5$303nc$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 03 Sep 2024 09:29:23 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="93d7d6b8e3b40fe75b60c4526d162769";
	logging-data="3423947"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19/CH3WODoB6GBE4D5Fg1zE1BlV8p0H7xw="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:HKbO5Iec79i3EqephWZnuAswFWg=
Content-Language: en-GB
In-Reply-To: <vb58i5$303nc$1@dont-email.me>
Bytes: 4898

On 02/09/2024 22:52, Thomas Koenig wrote:
> Thomas Koenig <tkoenig@netcologne.de> schrieb:
> 
>> "Don't do this" or "don't do that" is not sufficient.  Maybe you,
>> together with like-minded people, could try formulating some rules
>> as an extension to the C standard, and see where it gets you.
>> Maybe you can get it published as an annex.
> 
> Hm... putting some thought into it, it may be a good first step
> to define cases for which a a diagnostic is required; maybe
> "observable error" would be a reasonable term.
> 

That sounds a lot like adding a new type of run-time error handling to 
the language.  That's not necessarily a bad idea, but it would likely be 
a very big change with significant ramifications for existing code.

> So, put "dereferencing a NULL pointer shall be an observable
> error" would make sure that no null pointer checks are thrown
> away, and that this requires a run-time diagnostic.
> 

The kind of null pointer checks that are thrown away by some compilers 
are those that come /after/ a dereference :

	int foo(int * p) {
		int x =  *p;
		if (!p) {
			printf("I shouldn't have done that...\n");
		}
		return x;
	}

If dereferencing a null pointer is an "observable error", it needs to be 
observed at the "int x = *p;" line, and has no influence on the deletion 
of the later pointer check.

Making dereferencing a null pointer an "observable error" would mean 
requiring compilers to insert an explicit check in a large number of 
cases, with a jump to some kind of run-time error-handling code when it 
is zero.  That is a very significant cost, to be paid by all users of 
pointers in C - even those that are careful to ensure that their 
pointers are not null before calling "foo".  (There's also the 
definition complications - a pointer that happens to contain the value 
0, or point to address 0, is not necessarily a NULL pointer, and on some 
targets there are lots of different values that are all null pointers. 
And there are endless possibilities for invalid pointers that are not null.)

C is a language where the programmer takes the responsibility to get the 
code right - not the language or run-time.  It insists on manual and 
explicit control of this kind of thing, so that you don't have to pay 
for checks you don't want.

Leaving the dereferencing of invalid pointers as undefined behaviour 
means that code that does not have invalid pointers does not have extra 
hidden checks and costs, along with hidden jumps to error handlers.  It 
also means that development tools can run in modes that add whatever 
they like of extra checks and handling of invalid pointers - 
"sanitizers" and other run-time checkers.  And static error checkers can 
warn if they see code paths with bad dereferences.

> If that is the case, should dereferencing a member of a struct
> pointed to by a null pointer also be an observable error, and
> be required to be caught at run-time?
> 
> Or is this completely the wrong track, and you would like to do
> something entirely different?  Any annex to the C standard would
> still be constrained to the abstract machine (probably).