[openssl-dev] [openssl.org #3950] Standard mem* functions called with length 0 and invalid pointer arguments

[Kurt Roeckx via RT]

On Wed, Jul 22, 2015 at 10:23:40AM +0000, Pascal Cuoq via RT wrote:
> Recently, GCC began to assume for optimization purposes that p and q are non-null pointers when
> memcpy(p, q, n); is invoked.

I have to agree that p and q can't be NULL, even when n is 0.  The
standard seems to be rather clear about that.

> Clause 7.1.4 also allows compilers to assume that p and q are not pointers "one past" the end of an object:
> 
> http://stackoverflow.com/questions/25390577/is-memcpya-1-b-1-0-defined-in-c11

It seems at least not everybody agrees on that, and it's non
obvious to me who is correct. Can I suggest someone takes that
question to the standard committee?


> OpenSSL's bignum implementation contains two invocations of standard functions that
> fail this property:
> 
> https://github.com/openssl/openssl/blob/b39fc560612984e65ec30d7f37487303bf514fb3/crypto/bn/bn_add.c#L225
> https://github.com/openssl/openssl/blob/b39fc560612984e65ec30d7f37487303bf514fb3/crypto/bn/bn_mont.c#L199
> 
> These two lines are actually reached with pointers "one past" and sizes of 0 during real executions.

I'm unsure what the effect of it would be in case it's really
undefined behaviour.  I think the only thing gcc could assume is
that the pointers aren't NULL, which they aren't.  But that would
be the first undefined behaviour, not the second.


Kurt