* Silly question about strncpy(), strlen() and related funcs @ 2012-06-18 18:54 orc 2012-06-18 20:35 ` Szabolcs Nagy 2012-06-18 21:48 ` Rich Felker 0 siblings, 2 replies; 5+ messages in thread From: orc @ 2012-06-18 18:54 UTC (permalink / raw) To: musl 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Silly question about strncpy(), strlen() and related funcs 2012-06-18 18:54 Silly question about strncpy(), strlen() and related funcs orc @ 2012-06-18 20:35 ` Szabolcs Nagy 2012-06-19 6:44 ` orc 2012-06-18 21:48 ` Rich Felker 1 sibling, 1 reply; 5+ messages in thread From: Szabolcs Nagy @ 2012-06-18 20:35 UTC (permalink / raw) To: musl * 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) ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Silly question about strncpy(), strlen() and related funcs 2012-06-18 20:35 ` Szabolcs Nagy @ 2012-06-19 6:44 ` orc 0 siblings, 0 replies; 5+ messages in thread From: orc @ 2012-06-19 6:44 UTC (permalink / raw) To: musl 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Silly question about strncpy(), strlen() and related funcs 2012-06-18 18:54 Silly question about strncpy(), strlen() and related funcs orc 2012-06-18 20:35 ` Szabolcs Nagy @ 2012-06-18 21:48 ` Rich Felker 2012-06-19 6:44 ` orc 1 sibling, 1 reply; 5+ messages in thread From: Rich Felker @ 2012-06-18 21:48 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Silly question about strncpy(), strlen() and related funcs 2012-06-18 21:48 ` Rich Felker @ 2012-06-19 6:44 ` orc 0 siblings, 0 replies; 5+ messages in thread From: orc @ 2012-06-19 6:44 UTC (permalink / raw) To: musl 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-06-19 6:44 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-06-18 18:54 Silly question about strncpy(), strlen() and related funcs orc 2012-06-18 20:35 ` Szabolcs Nagy 2012-06-19 6:44 ` orc 2012-06-18 21:48 ` Rich Felker 2012-06-19 6:44 ` orc
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).