Ordering dependency between string.h and strings.h.

Rich Felker dalias at aerifal.cx
Sat Dec 23 00:53:52 UTC 2006


On Fri, Dec 22, 2006 at 09:30:01PM +0100, Christian MICHON wrote:
> sorry there was a typo mistake in the 1st paragraph.
> when including both strings.h and string.h chokes the
> compiler, it's better to have only *string.h* included.
> 
> On 12/22/06, Christian MICHON <christian.michon at gmail.com> wrote:
> > you're supposed to choose to include *only* one, and actually
> > strings.h is the better choice if I recall well.
> >

Your reply is incorrect anyway, and please don't top-post. string.h is
the ANSI/ISO C header with the standard functions. strings.h existed
on various odd legacy systems and it's the place to which SUSv3 has
relegated various deprecated and legacy functions which should not be
used. 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...).

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.

Rich





More information about the uClibc mailing list