[openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details
jb-openssl at wisemo.com
Wed Jan 11 16:34:58 UTC 2017
On 11/01/2017 16:32, Stephan Mühlstrasser wrote:
> Am 03.01.17 um 21:26 schrieb Viktor Dukhovni:
>>> On Jan 3, 2017, at 2:55 PM, Ken Goldman <kgoldman at us.ibm.com> wrote:
>>> 1 - Is this a bit of a bug?
>>> ECDSA_SIG_free() frees the r and s BIGNUMs before is frees the
>>> structure itself. However, ECDSA_SIG_new() doesn't set r and s to
>>> NULL. It calls zalloc, which sets them to 0x00 bytes.
>>> OK, in most platforms, the NULL pointer is an all 0x00 bytes value,
>>> but it's not guaranteed by the C standard.
>>> E.g., http://c-faq.com/null/confusion4.html
>> OpenSSL does not support platforms where the memory representation of
>> NULL pointer contains non-zero bytes. IIRC there are even tests for
> 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 am not from the OpenSSL team either, but the probable thinking is
The C (and C++) standard allows a number of things that are very rare
in practice, while providing very few guarantees about important
aspects of semantics. Therefore most major cross-platform projects
will usually take a number of common-sense aspects that are already
common among the desired platforms and elevate them into "project-
specific" requirements, foregoing the option to port the code to
platforms that differ in those aspects. This provides a more robust
and usable "dialect" of the C/C++ language, allowing code to not do
things that are clumsy, slow, error-prone or otherwise difficult.
For the specific requirement of NULL pointers being encoded as an
all-0 bit pattern (and the similar requirement for 0 integral values),
this allows the use of zero-initializing memory allocators/handlers to
forego the need to explicitly initialize NULL (and 0) field and array
Note that C++ has a similar, but weaker, requirements that the source
code literal 0 is a valid syntax for null pointer constants and that
many (but not all) uninitialized pointer and numeric fields should be
implicitly initialized to NULL / 0 by compiler generated code, which
doesn't cover the case of memory blocks that don't get to run the
(implicit) C++ constructor.
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
More information about the openssl-users