https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86259
--- Comment #42 from Alejandro Colomar <alx at kernel dot org> --- I'm very confused by this ticket. The discussion seems to be settled by Martin Sebor that the presented code has UB due to pointer provenance issues, according to the WG14 interpretation of the standard. GCC historically had relaxed rules on mem*() functions, to let old code work as expected. This is by no means required by ISO C, and is only a GNU extension. ISO C is stricter and under its rules, memcpy(3) cannot cross subobject boundaries. This is the ideal behavior, and the intention is to tighten the rules so that code analysis becomes easier. Nobody seemed to rebute Martin's analysys that it's UB with solid ground, and I agree that it looks like UB. Did I understand that correctly? And then I see that something has been 'fixed' in GCC, and that the ticket is marked as RESOLVED FIXED. This is very confusing, since nothing in the ticket really documents what was broken. It seems that GCC's relaxed rules on mem*() functions were extended to cover str*() functions too. May I ask why? And may I ask a -fprovenance to get strict provenance rules? I find very confusing when code breaks provenance rules, because simlarly to how a compiler will have trouble analyzing the code, a human brain will have trouble understanding where some copy data came from (at least that's true for mine). See the following question, which seems to be very related to pointer provenance rules: <https://software.codidact.com/posts/288138>. I'd like to be able to guarantee that in my code nobody messes with pointers to get magic copies out of nowhere. Thanks.
