> From: openssl-users [mailto:openssl-users-bounces@xxxxxxxxxxx] On Behalf > Of Jeffrey Walton > Sent: Wednesday, January 11, 2017 11:19 > To: OpenSSL Users > Subject: Re: 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
