Re: Computer architects leaving Intel...

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).