> From: openssl-users [mailto:openssl-users-bounces@xxxxxxxxxxx] 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 -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
