Re:x86 Assembly Primer for C Programmers
by frozeneskimo on Monday March 26, 2012 @01:23AM
(#3755130)
Yeah, I see your point. Like you said, page alignment and size being a multiple of 4 won't cause a page fault, so it's technically "ok". I can only assume that at this level the corner is safely cut for the sake of performance.
Another more trivial example of something like this is in the repnz-based strlen() (slides 7-8), where %ecx is loaded with 0xffff ffff, which technically limits the routine to scan strings up to 4 gigabytes in length. It's a valid assumption that the string is under 4GB (especially on a strictly 32-bit system), but the point is that it's a semantically different routine than the C based one.
~vsergeev/frozeneskimo
(signatures are frowned upon around here)
Re:x86 Assembly Primer for C Programmers
by frozeneskimo on Monday March 26, 2012 @10:18AM
(#3756769)
(I see, my bad. Habit of mine. Thanks)
"If they read over (i.e. the NULL byte is in byte position 1 2 or 3), isn't that technically undefined behavior?"
Only if they are using C, not implementing it. That is why the C standard has that 'undefined behavior' claus. It makes optimizations like this possible.
Maybe you or someone else knows the answer to this though: it seems like they are processing 4 bytes of the string at a time. If they read over (i.e. the NULL byte is in byte position 1 2 or 3), isn't that technically undefined behavior? They are only reading in the memory, but I feel like valgrind or another tool would spit out an error if that happened. It's aligned, so it won't trigger a page fault, but it seems like an unsafe optimization.