<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 23, 2015, at 4:03 PM, Rafael Espíndola <<a href="mailto:rafael.espindola@gmail.com" class="">rafael.espindola@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><p dir="ltr" class="">.<br class="">
><br class="">
><br class="">
> Even if the string table is in in-order in practice, you have to search for NUL characters byte-by-byte unless it's really guaranteed to be in-order, no?<br class="">
></p><p dir="ltr" class="">No. Let's say we are at symbol N and want to find its size. Each symbol in the bsd format is represented with a pair of offsets. One to the member and one to the string table.</p><p dir="ltr" class="">We should be able to compute the symbol name size as the difference from the current symbol string table offset and the next symbol string table offset.<br class=""></p></div></blockquote>This is making an assumption that the string table is in the same order as the ranlib structs. While the llvm-ar tool does this it is not guaranteed by the format. One could imagine an ar(1) tool when there are multiple archive members defining the same symbol the string table entry for the symbol name is reused to save space.<br class=""><blockquote type="cite" class=""><div class=""><p dir="ltr" class="">Cheers, Rafael </p>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:LLVMdev@cs.uiuc.edu" class="">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" class="">http://llvm.cs.uiuc.edu</a><br class=""><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" class="">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br class=""></div></blockquote></div><br class=""></body></html>