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

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

[orc]

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?

Thanks.

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

[Szabolcs Nagy]

* orc <orc@sibserver.ru> [2012-06-19 02:54:09 +0800]:
> 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?

i assume you meant stpncpy.c

it checks whether s(ource) and d(estination) pointers
have the same alignment relative to word boundaries


(uintptr_t)s makes the pointer available for integer arithmetics

ALIGN is a bit mask 00..01..11 such that a word aligned pointer
has 0 bits where ALIGN has 1s

so the expression
  (uintptr_t)s & ALIGN
checks if s is word aligned

(eg on 32bit systems a word aligned pointer is a multiple of 4
so it should end with two 0s)

(alignment matters because even though the granularity of
addressing is 1byte, load/store of >1byte objects can
only be done (efficiently) with certain alignment)

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

[Rich Felker]

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

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

[orc]

On Mon, 18 Jun 2012 22:35:14 +0200
Szabolcs Nagy <nsz@port70.net> wrote:

> * orc <orc@sibserver.ru> [2012-06-19 02:54:09 +0800]:
> > 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?
> 
> i assume you meant stpncpy.c

Yes, my typo.

> 
> it checks whether s(ource) and d(estination) pointers
> have the same alignment relative to word boundaries
> 
> 
> (uintptr_t)s makes the pointer available for integer arithmetics
> 
> ALIGN is a bit mask 00..01..11 such that a word aligned pointer
> has 0 bits where ALIGN has 1s
> 
> so the expression
>   (uintptr_t)s & ALIGN
> checks if s is word aligned
> 
> (eg on 32bit systems a word aligned pointer is a multiple of 4
> so it should end with two 0s)
> 
> (alignment matters because even though the granularity of
> addressing is 1byte, load/store of >1byte objects can
> only be done (efficiently) with certain alignment)

Thanks for explanation. I've already seen in debugger that it works with
pointers, but how it works with them was somewhat cryptic for me.
Rich's explanation below helped me to understand the rest of code.

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

[orc]

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.