[Mark Phippard]
> I did some digging on the two compiled objects and noticed that they
> were linking different runtime functions (Subversion was apparently
> linking the EBCDIC version). I went back to IBM with this and we
> each did some more digging and appear to have figured it out:
>
> Subversion uses #include <string.h> but to get the UTF8 support in
> this function on OS/400 you need to #include <strings.h>. Does this
> make sense to anyone?
Traditionally, <strings.h> is from the BSD Unix world and <string.h> is
from the AT&T Unix world. This was one of those little
incompatibilities between Unix systems, back in the day, that made
autoconf so popular. These days, all systems have both header files
and both sets of functions. The AT&T string functions won the culture
war, such as it was, so <string.h> is all most people use anymore.
strcasecmp is also from BSD and was declared in <strings.h>. In some
environments nowadays it's also declared in <string.h>, but not all.
It may be that your UTF-8 build environment uses tricks like:
/* ... in <strings.h> ... */
char *utf8_strchr(const char *, int);
char *utf8_strrchr(const char *, int);
char *utf8_strcasecmp(const char *, const char *);
#define index utf8_strchr
#define rindex utf8_strrchr
#define strcasecmp utf8_strcasecmp
i.e., the names of the functions are redefined, because both UTF-8 and
EBCDIC versions are available in the same libraries. That would
explain the observed behavior: function names aren't redefined to use
the UTF-8 version.
Note that in C, function prototypes are not required, so you often
don't even notice forgetting to include the correct header file.
(There are warnings you can enable to catch this.)
Received on Fri Feb 17 10:09:24 2006