> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Jeffrey Walton
> Sent: Wednesday, January 11, 2017 11:19
> To: OpenSSL Users
> Subject: Re: [openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details
>
> > Could someone from the OpenSSL team please explain the rationale for
> this
> > decision? What is the problem with using assignments with 0 or NULL to
> > initialize pointers?
>
> I'm not from the team, so take it for what its worth...
>
> On some systems, NULL is _not_ 0. NULL can be anywhere in memory the
> architecture wants it to be. It can be in a high page in memory, too.
This comment is misleading (as was Rich Salz's reply). Jeffrey's question, as
phrased, is correct.
The definition of the NULL macro is mandated by the C standard. It is either an
integer constant that evaluates to 0, or such a constant cast to void*.
The representation in memory of a null pointer need not be all-bits-zero. (The
representation in memory of an integer constant with the value zero can either
be all-bits-zero or, in the unlikely case of sign-magnitude integers, a sign
bit of 1 followed by all-other-bits-zero.)
In other words, *in C source code* a null pointer is *always* created by
assigning the NULL macro, or a literal 0, or such a thing cast to an
appropriate pointer type, to a pointer variable. Even if the representation of
a null pointer in memory is not all-bits-zero. Similarly, comparing a null
pointer to a literal 0 evaluates as true, regardless of the representation of
null pointers. That's required by the C standard; if it doesn't work, you're
using a language which is almost but not quite entirely unlike C.
However: Operations such as memset(object_pointer, 0, size) may NOT create null
pointers, because memset simply sets the underlying bits without any knowledge
of types or representations.
And that's why many programs don't work on implementations where the null
pointer representation is not all-bits-zero: because they use shortcuts like
memset and calloc to "clear" pointers (generally as part of structs containing
pointer fields), rather than doing it properly.
Doing it properly, incidentally, looks like this:
static const struct foo foo0; /* implicitly equivalent to ... foo0 =
{0} */
...
struct foo *bar = malloc(sizeof *bar);
*bar = foo0;
Unfortunately writing proper C is a rare skill - relatively few C programmers
have ever even read the language specification - and much C code is saddled
with lots of ancient technical debt. Also, of course, it often doesn't make
economic sense to accommodate rare implementations. How many C programs work
correctly on implementations where CHAR_BIT > 8?
Michael Wojcik
Distinguished Engineer, Micro Focus
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
