[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: apr_strnatcasecmp vs. strcasecmp

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2006-02-21 23:57:05 CET

On Tue, 2006-02-21 at 14:42 -0500, Mark Phippard wrote:
> I sent ghudson's reply to IBM. This was their reply. I probably should
> not bother to post this, but it seemed interesting and relevant to the
> discussion and the subsequent patch.
[Boils down to:]
> So i5/OS is compliant to the newest/latest standards.

Yes, that's not at all inconsistent with what I said. But standards
like POSIX and SUS should not be taken as an excuse for not defining
commonly-expected symbols where they are commonly defined on other
Unix-type systems, unless the compiler has been asked to provide a clean
namespace for a particular standard. Various Unix-type systems have
taken the "minimally standards-compliant" approach, and they are always
known as the annoying ones to port to.

As an example of how most systems do it right, Solaris's <string.h>
contains:

#if defined(__EXTENSIONS__) || (__STDC__ == 0 && \
                !defined(_POSIX_C_SOURCE) && !defined(_XOPEN_SOURCE))
[some other stuff]
extern int strcasecmp(const char *, const char *);
extern int strncasecmp(const char *, const char *, size_t);
[some other stuff]
#endif /* defined(__EXTENSIONS__)... */

Basically, if you *haven't* asked for a clean namespace for ANSI C
(__STDC__ == 0 is the default for Solaris compilers), POSIX, or XOPEN,
or if you've asked for extensions to one of those standards, you get the
functions code has come to expect from <string.h> on modern BSD, Linux,
and other systems.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 21 23:58:08 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.