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 _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
