On 12/01/2017 12:19, Salz, Rich wrote:
It was a mix of what was done, and then a conscious decision to do things that
way.
As for the PR, well, maybe... We'd need to know details of which machine
"test/sanitytest.c" fails on, and how popular it is to see if it's worthwhile.
That would be in
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf
> Of Stephan Mühlstrasser
> Sent: Thursday, January 12, 2017 07:50
>
> I think IBM iSeries is affected by this, but I still have to verify this.
It's been years since I worked on the iSeries (in fact, it was mostly prior t
Am 12.01.17 um 13:19 schrieb Salz, Rich:
My question was meant to ask why the pointers are initialized with
memset() instead of initializing them by an assignment with NULL or 0.
Was this a deliberate decision for some reason, or did it just creep in and no
one cares now to fix it? Would the Open
> My question was meant to ask why the pointers are initialized with
> memset() instead of initializing them by an assignment with NULL or 0.
> Was this a deliberate decision for some reason, or did it just creep in and no
> one cares now to fix it? Would the OpenSSL team accept pull requests that
Am 11.01.17 um 17:09 schrieb Salz, Rich:
OpenSSL does not support platforms where the memory representation of
the NULL pointer contains non-zero bytes. IIRC there are even tests for
this.
Could someone from the OpenSSL team please explain the rationale for this
decision? What is the problem wi
ISO/C 2011, clause 6.3.2.3:
An integer constant expression with the value 0, or such an expression cast to
type void *, is called a null pointer constant. If a null pointer constant is
converted to a pointer type, the resulting pointer, called a null pointer, is
guaranteed to compare unequa
On Wed, Jan 11, 2017 at 05:27:47PM +, Michael Wojcik wrote:
> 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 m
> 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.)
And, agai
> 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
> I suspect that it was a shortcut, where they used memset() on an entire
> structure, and it hopefully set pointers to NULL.
>
> What I pointed out is that if NULL is not all zeros, this breaks.
And OpenSSL does not work on those platforms. It is part of the test suite to
check for this. See
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 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
On 1/11/2017 10:32 AM, Stephan Mühlstrasser wrote:
OpenSSL does not support platforms where the memory representation of the
NULL pointer contains non-zero bytes. IIRC there are even tests for this.
Could someone from the OpenSSL team please explain the rationale for
this decision? What is the
> 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
> > OpenSSL does not support platforms where the memory representation of
> > the NULL pointer contains non-zero bytes. IIRC there are even tests for
> this.
>
> Could someone from the OpenSSL team please explain the rationale for this
> decision? What is the problem with using assignments with 0
Am 03.01.17 um 21:26 schrieb Viktor Dukhovni:
On Jan 3, 2017, at 2:55 PM, Ken Goldman 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
> OpenSSL does not support platforms where the memory representation of
> the NULL pointer contains non-zero bytes. IIRC there are even tests for this.
Yes, the basic platform sanity tests, test/sanitytest.c
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/op
> On Jan 3, 2017, at 2:55 PM, Ken Goldman 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 pla
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
18 matches
Mail list logo