Messages in this thread | | | From | Rasmus Villemoes <> | Subject | Re: [PATCH] string: Improve the generic strlcpy() implementation | Date | Mon, 19 Oct 2015 14:42:34 +0200 |
| |
On Mon, Oct 05 2015, Ingo Molnar <mingo@kernel.org> wrote:
> * Linus Torvalds <torvalds@linux-foundation.org> wrote: > >> On Thu, Sep 10, 2015 at 8:43 PM, Chris Metcalf <cmetcalf@ezchip.com> wrote: >> > >> > Please pull the following changes for 4.3 from: >> > >> > git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile.git strscpy >> >> So I finally pulled it. I like the patch, I like the new interface, >> but despite that I wasn't really sure if I wanted to pull it in - thus >> the long delay of me just seeing this in my list of pending pulls for >> almost a month, but never really getting to the point where I decided >> I want to commit to it. > > Interesting. I noticed that strscpy() says this in its comments: > > * In addition, the implementation is robust to the string changing out > * from underneath it, unlike the current strlcpy() implementation.
Apologies for beating a dead horse, but:
c = *(unsigned long *)(src+res); if (has_zero(c, &data, &constants)) { data = prep_zero_mask(c, data, &constants); data = create_zero_mask(data); *(unsigned long *)(dest+res) = c & zero_bytemask(data); return res + find_zero(data); } *(unsigned long *)(dest+res) = c;
I wonder whether an insane compiler might actually reload c before storing to dest+res, so that we'd have exactly the same problem of embedded nul characters? And similarly in the byte-by-byte case:
char c;
c = src[res]; dest[res] = c; if (!c) return res;
(yes, there's a store between the load and the test, and the compiler probably can't know or prove that src and dest don't alias - but we're storing c, so a sufficiently clever _and_ insane compiler could test src[res]). Would READ_ONCE be justified?
Rasmus
| |