Avoid passing out-of-bound pointers to 0-size memcpy #879

1. 
   sipa commented at 5:57 am on January 24, 2021: contributor

   Doing so could be considered UB in a pedantic interpretation of the standard. Avoid it.

   Closes #876.

2. Avoid passing out-of-bound pointers to 0-size memcpy

   Doing so could be considered UB in a strict reading of the standard.
   Avoid it.

   9570f674cc
3. 
   practicalswift commented at 7:50 am on January 24, 2021: contributor

   cr ACK 9570f674cc729cafcba65f4cce03552d9a6108f4: patch looks correct
4. 
   real-or-random commented at 5:53 pm on January 24, 2021: contributor

   When we change the contrib functions, we should also consider changing the copies in Bitcoin Core, see #781 edit: What I’m saying is: Let’s take care of this in #781.

   Can you also change the comparison in the same function here https://github.com/bitcoin-core/secp256k1/blob/9570f674cc729cafcba65f4cce03552d9a6108f4/src/ecdsa_impl.h#L115

   to read rlen > (size_t)(sigend - *sig) ? This will never compute an out-of-bounds pointer (which is another case of pedantic UB).

5. 
   real-or-random commented at 6:46 am on June 11, 2021: contributor

   @sipa ping
6. 
   real-or-random commented at 8:19 am on June 16, 2021: contributor

   ACK 9570f674cc729cafcba65f4cce03552d9a6108f4

   I’ll open a new PR for the other issue

7. real-or-random merged this on Jun 16, 2021
8. real-or-random closed this on Jun 16, 2021

   ---

9. real-or-random cross-referenced this on Jun 16, 2021 from issue Avoid computing out-of-bounds pointer. by real-or-random
10. apoelstra cross-referenced this on Jul 27, 2021 from issue Upstream PRs 879, 959, 955, 944, 951, 960, 844, 963, 965 by apoelstra
11. real-or-random referenced this in commit 920a0e5fa6 on Oct 17, 2021

Contributors
sipa practicalswift real-or-random