Ordering dependency between string.h and strings.h.

[Rob Landley]

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.

> There is, however, apparently a bug in the uclibc headers. I suspect
> that strings.h assumes that string.h already included prototypes for
> the legacy functions, while actually string.h will only prototype them
> if you've used -D_{GNU,BSD}_SOURCE or similar.

It's already got #define _GNU_SOURCE because I'm using something else that 
needed it.  (I forget what.)

Broken:
http://landley.net/hg/firmware?f=4e169fd589d8;file=sources/toys/gcc-uClibc.c

The fix:
http://landley.net/hg/firmware?fd=f393a630a5b3;file=sources/toys/gcc-uClibc.c

> Rich

Rob
-- 
"Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away." - Antoine de Saint-Exupery