tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: NULL pointer arithmetic issues



At Mon, 9 Mar 2020 17:36:24 +0100, Joerg Sonnenberger <joerg%bec.de@localhost> wrote:
Subject: Re: NULL pointer arithmetic issues
>
> I consider it as something even worse. Just like the case of passing
> NULL pointers to memcpy and friends with zero as size, this
> interpretation / restriction in the standard is actively harmful to some
> code for the sake of potential optimisation opportunities in other code.
> It seems to be a poor choice at that. I.e. it requires adding
> conditional branches for something that behaves sanely everywhere but
> may the DS9k.

Indeed.

I way the very existence of anything called "Undefined Behaviour" and
its exploitation by optimizers is evil.  (by definition, especially if
we accept as valid the claim that "Premature optimization is the root of
all evil in programming" -- this is of course a little bit of a stretch
since my claim could be twisted to say that any and all automatic
optimzation by a compiler or toolchain is evil, but of course that's not
exactly my intent -- normal optimization which does not change the
behaviour and intent of the code is, IMO, OK, but defining "intent" is
obviously the problem)

So in Standard C all "Undefined Behaviour" should be changed to
"Implementation Defined" and it should be required that the
implementation is not allowed to abuse any such things for the evil
purpose of premature optimzation.  For this kind of thing adding an
integer to a pointer (or the equivalent, e.g. taking the address of a
field in a struct pointed to by a nil pointer) should always do just
that, even if the pointer can be proven to be a nil pointer at compile
time.  It is wrong to do anything else, and absolute insanity to remove
any other code just because the compiler assumes SIGSEGV
would/should/could happen before the other code gets a chance to run.

--
					Greg A. Woods <gwoods%acm.org@localhost>

Kelowna, BC     +1 250 762-7675           RoboHack <woods%robohack.ca@localhost>
Planix, Inc. <woods%planix.com@localhost>     Avoncote Farms <woods%avoncote.ca@localhost>

Attachment: pgpimuTvZUcEO.pgp
Description: OpenPGP Digital Signature



Home | Main Index | Thread Index | Old Index