Sebastian Schuberth <sschube...@gmail.com> writes: > On Thu, Sep 12, 2013 at 10:08 PM, Junio C Hamano <gits...@pobox.com> wrote: > >>> I'm not too happy with the wording either. As I see it, even on MinGW >>> runtime version 4.0 it's not true that "string.h has _only_ inline >>> definition of strcasecmp"; there's also "#define strncasecmp >>> _strnicmp" which effectively provides a non-inline definition of >>> strncasecmp aka _strnicmp. >> >> I do not get this part. Sure, string.h would have definitions of >> things other than strcasecmp, such as strncasecmp. So what? > > Sorry, I mixed up "strcasecmp" and "strncasecmp".
OK. >> Does it "effectively" provide a non-inline definition of strcasecmp? > > Yes, if __NO_INLINE__ is defined string.h provides non-inline > definition of both "strcasecmp" and "strncasecmp" by defining them to > "_stricmp" and "_strnicmp" respectively. > >> Perhaps the real issue is that the header file does not give an >> equivalent "those who want to take the address of strcasecmp will >> get the address of _stricmp instead" macro, e.g. >> >> #define strcasecmp _stricmp >> >> or something? > > Now it's you who puzzles me, because the header file *does* have > exactly the macro that you suggest. Then why does your platform have problem with the code that takes the address of strcasecmp and stores it in the variable? It is not me, but your platform that is puzzling us. There is something else going on, like you do not have that #define "enabled" under some condition, or something silly like that. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
