Re: Silly question about strncpy(), strlen() and related funcs

[orc <orc@sibserver.ru>]

On Mon, 18 Jun 2012 17:48:21 -0400
Rich Felker <dalias@aerifal.cx> wrote:

> On Tue, Jun 19, 2012 at 02:54:09AM +0800, orc wrote:
> > Did not reached Rich privately, so I want to ask publicly:
> > 
> > What ALIGN and additional checks like 'if (((uintptr_t)s & ALIGN) ==
> > ((uintptr_t)d & ALIGN))' {...} are mean in src/string/strpcpy.c and
> > similiar functions?
> 
> Hi. Sorry I didn't get back to you earlier. I meant to but lost your
> email amidst all the gnulib stuff.
> 
> The point of this test is that we want to copy larger data units at a
> time (system word size) instead of single bytes if possible, but this
> is only portable if the source and destination of each read and write
> is properly aligned. The initial addresses don't have to be aligned as
> long as their remainder modulo the alignment is the same; the initial
> misaligned part can be copied byte-at-a-time, and as long as the
> the source and destination misalignment initially matched, they'll
> both be aligned for word-at-a-time copying after the initial segment.
> 
> Some systems, such as x86, would actually allow misaligned
> reads/writes in general, but we still need to avoid them for many
> functions. Why? Because a misaligned read might cross page boundaries
> into an unreadable/nonexistant page, and thereby cause SIGSEGV or
> SIGBUS. Reading past the end of a string is no problem as long as we
> stay in the same page, so it could work on x86 if we align the source
> address and just leave the destination possibly misaligned, but x86 is
> about the _only_ arch where that's safe, and if we really want to take
> advantage of larger-unit copies in the misaligned case, I think it
> should just be done with x86 asm rather than adding special cases in
> the C code. With asm, we could also use the string functions (rep
> movsd etc.) which give optimal performance on most cpus.
> 
> Rich

Thanks for the detailed explanation. Just wondered that BSDs implement
only one-byte-at-a-time versions of this functions.
Interesting code, always learning something new.