[openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details

[Michael Wojcik]

> From: openssl-users [mailto:openssl-users-bounces at 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 to the rename, so it was still OS/400 then); but IIRC the null-pointer representation was all-bits-zero for all of the IBM C implementations (EPM C, System/C, and ILE C).

The '400 / iSeries has an interesting pointer representation - 16 bytes, with a validity bit that can't be altered by user-mode code, to prevent constructing arbitrary pointers. It's a capabiltiy architecture, more or less. But in order to improve compatibility with pre-standard and poor C code, the C implementations recognize all-bits-zero in a pointer-type object as a null pointer. And attempting to dereference (via the MI MATPTR instruction) such an object raises the appropriate machine check (or program check? it's been a while).


In my experience, the real problems caused by non-conforming C code are more subtle. One thing that definitely *will* bite C programs on iSeries, for example, is failing to correctly declare a function that returns a pointer type, such as malloc - because an undeclared function is assumed to return int, and sizeof(int) < sizeof(void*) in those implementations.

And don't even get me started on calling undeclared functions on Itanium-based implementations...

Michael Wojcik 
Distinguished Engineer, Micro Focus