Peter Samuelson <peter@p12n.org> wrote on 02/17/2006 04:08:32 AM:
> 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.
Greg Hudson <ghudson@MIT.EDU> wrote on 02/17/2006 12:59:59 PM:
> On Fri, 2006-02-17 at 10:42 -0500, Mark Phippard wrote:
> > Thanks, the IBM compiler team essentially gave the same answer.
> > Ultimately, this function is only declared in strings.h and the
compiler
> > issues a warning that we were missing when the prototype is not found.
> > Since the C runtime has a function named strcasecmp (for EBCDIC
strings)
> > the linker does not have a problem.
>
> Ugh. IBM's header files are apparently trying to be compatible with
> 20-year-old System V and BSD, and could use an update. It's true that
> strcasecmp and strncasecmp came from BSD which at first used
> <strings.h>, but it's been a while since any popular Unix system didn't
> make <string.h> and <strings.h> mostly identical, and declare
> strcasecmp/strncasecmp in both. (Unless you've asked for a clean
> namespace for a particular standard which doesn't include those
> functions.)
A big thanks to all who helped out on this. You are correct, IBM is
behind the times with their header files. Fortunately, the solution to
our problem appears to be quite simple: include strings.h in the OS400
svn_private_config.h. strcasecmp links with the correct (non EBCDIC)
version of the function and no OS400 specific patch is required.
Paul B.
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Feb 20 15:24:56 2006