On Wed, 2 Apr 2025 17:08:51 -0700 Peter Collingbourne <pcc@xxxxxxxxxx> wrote: > On Wed, Apr 2, 2025 at 1:10 PM Catalin Marinas <catalin.marinas@xxxxxxx> wrote: .. > > Reading across tag granule (but not across page boundary) and causing a > > tag check fault would result in padding but we can live with this and > > only architectures that do MTE-style tag checking would get the new > > behaviour. > > By "padding" do you mean the extra (up to sizeof(unsigned long)) nulls > now written to the destination? It seems unlikely that code would > deliberately depend on the nulls not being written, the number of > nulls written is not part of the documented interface contract and > will vary right now depending on how close the source string is to a > page boundary. If code is accidentally depending on nulls not being > written, that's almost certainly a bug anyway (because of the page > boundary thing) and we should fix it if discovered by this change. There was an issue with one of the copy routines writing beyond the expected point in a destination buffer. I can't remember the full details, but it would match strscpy(). David
