On 03/14/2016 05:52 PM, Martin Sebor wrote: >> The only reason not to do this is that the address of the strchr >> function will not be consistent across the entire process. Do you think >> this could be a problem, even just a conformance problem? > > I'm not sure I understand the concern. There can be up to three > overloads of strchr in a program (one extern "C" and two extern > "C++" if the program includes C++ bits). Each of the overloads > must has its own distinct address (and name) but that address of > the same overload needs to be the same across the whole program > (though the C bits will never see the C address and the C++ bits > have no way of accessing the C address in conforming programs). > As long as this invariant is maintained I don't think there is > a problem. I think I did my test with “static inline”. In this case, each translation unit gets its own out-of-line copy if the address of the function is taken. This does not happen with “inline” or “extern inline”; there is just a single copy in this case. I think this means it's an all-around improvement to replace the asm aliases in glibc with inline function wrappers, as suggested here: https://sourceware.org/bugzilla/show_bug.cgi?id=19618 The inline wrappers help non-GCC compilers, and current GCC produces better code because it will recognize strchr as such, which currently does not happen due to the asm alias. Thanks, Florian
