Ordering dependency between string.h and strings.h.

[Kevin Day]

On 12/23/06, Rich Felker <dalias at aerifal.cx> wrote:
> On Fri, Dec 22, 2006 at 11:37:23PM -0500, Rob Landley wrote:
> > On Friday 22 December 2006 7:53 pm, Rich Felker wrote:
> > > Your reply is incorrect anyway, and please don't top-post.
> >
> > *shrug*  I didn't see it.  He's in my spam filter.
> >
> > > There is nothing wrong with including both strings.h and
> > > string.h (except that you probably shouldn't be using the functions in
> > > strings.h at all...).
> >
> > I've used index() since Borland C for DOS, it's been here for the entire
> > history of Linux, and I'm going to continue to use it.  I don't care what a
> > standards committe says about it.  Standards bodies should document, not
> > legislate.  Gratuitously renaming existing interfaces is sad.
>
> Standards bodies are there to document what's common to all systems,
> not your two [or whatever number of] pet systems. As far as I know
> there were two sets of functions for the same thing, present on
> different systems, and the reasonably named one was chosen as the
> standard one. Specifying many names for the same thing is not the job
> of a standard; it's the job of abominations like perl.
>
> Rich

Sorry to jump in, but in my curioisity I noticed the following:
- inside of strings.h there is a test for whether or not string.h is
already included (line 25).
  If string.h was included BEFORE strings.h, then string.h would not
include anything, unless you have __USE_BSD support enabled. (unless a
broken compiler ignores the ifndefs..)
- inside of string.h, there is no test for strings.h, probably causing
this order issue.  There is no "BSD/strings.h" test going on inside of
string.h
- This is rather inconsistant and will cause problems such as the one noted
- Assuming that the statement in the strings.h on why strings.h should
do nothing on non-bsd systems when string.h is included (and assuming
because I simply don't know), then there should probably be some check
in string.h that achieves the same purpose.

inside of string.h, something like the following could be used:
#if defined _STRINGS_H && !defined __USE_BSD
#error strings.h should not be included along with string.h on non-BSD systens
#endif

or #warning

There is another approach you might take and that would be adding some
flag such as "ALLOW_STRINGS_AND_STRING_H". Rather long, but I imagine
you can come up with a better name.  In this case, the end programmer
chooses whether they want to do crazy stuff or not and then it can
only be their problem. (CFLAGS="$CFLAGS -DALLOW..) Then, when
__USE_BSD is defined, simply handle in the same way that is currently
being done.

This is simply my suggestion, do with it as you will.
(: besides, if you don't do it and I somehow feel a need to do it, I
can always have my own patches :)

-- 
Kevin Day