Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Sorry for asking such a stupid question, but isn't that code horribly broken? It assumes that the next 3 byte after a string are readable. What if I malloc'ed memory for the string in such a way, that the \0 is the last byte of the memory page and the next byte after \0 is on the next page, which is not mapped into my VM space? In such a case the CPU will throw a page-fault and the process will die because of SIGSERV or SIGBUS. Or is the glibc version of malloc padding all memory to have at least 3 byte beyond its last byte?


The glibc strlen begins by checking the first few bytes, if necessary, so that it can continue with the assumption that the string is 4-byte or 8-byte aligned. So no, it's not horribly broken: all the reads are aligned, and you're not going to get a page boundary in the middle of the word.

(Also, you're not going to be reading off the end of a malloc'ed block, because essentially all malloc implementations, including the one in glibc, return blocks whose start address and size are multiples of the architecture's word size.)


Not directly related to your question, but see http://sourceware.org/bugzilla/show_bug.cgi?id=5807

The ((longword - lomagic) & himagic) should be ((longword - lomagic) & ~longword & himagic)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: