Add strings.h

[Corinna Vinschen]

On Dec  8 14:59, Ralf Corsepius wrote:
> On 12/08/2010 11:40 AM, Corinna Vinschen wrote:
> >On Dec  8 03:39, Ralf Corsepius wrote:
> >>On 12/08/2010 12:13 AM, Jeff Johnston wrote:
> >>>On 12/07/2010 05:03 PM, Eric Blake wrote:
> >>>>On 12/07/2010 10:32 AM, Jeff Johnston wrote:
> >>>>>>I suppose that would work as well, although my change is a one-liner.
> >>>>>>It's just that I don't have maintainer rights to approve your patch
> >>>>>>(although it does look okay to me, modulo the one #if line condition);
> >>>>>>so it's now time for Jeff or Corinna to speak up.
> >>>>>>
> >>>>>
> >>>>>Ralf's initial patch has just been applied.
> >>>>
> >>>>Any objections to pushing this?
> >>>>
> >>>
> >>>I'm fine with it.
> >>
> >>Thank you, Jeff, thank you, Eric.
> >
> >I just applied a patch to strings.h which removes the "#include<locale.h>'
> >and right afterwards it occured to me that I should better have started
> >by discussing it first.  Oops.
> >
> >The idea was this:  locale.h is only included to fetch the type locale_t
> >for the declaration of the new SUSv4 locale-aware functions
> >strcasecmp_l/strncasecmp_l.  IMHO it doesn't make sense to pull in
> >locale.h at this point in time, since locale_t doesn't yet exist, just
> >as the strcasecmp_l/strncasecmp_l functions.  Since the '#include
> ><locale.h>' doesn't fulfill it's only sense, it's just useless to
> >include it.
> >
> >I hope that makes sense...
> 
> I makes sense, in the sense as it is consistent with the direction
> taken elsewhere. However, I am not sure, I like this direction,
> because we should be aiming at encouraging folks to implement these
> missing functions.

It wasn't my intention to discourage implementing these functions.
Actually it was something I intended to do myself when I hacked on
the locale stuff this year, but got distracted by real life before
I could make the effort.
I'm still not entirely sure how to implement this exactly.  I had
a discussion with eblake on IRC a couple of months ago.  Basically
locale_t would have to be a pointer to a structure which contains
all the stuff from lmonetary.h, lmessage.h, etc.  LC_GLOBAL_LOCALE
should reference a global locale_t which contains all the stuff set
via setlocale.  struct reent would have to contain a locale_t so that
each thread could set another locale.  Oh, and, __ctype_ptr__
will have to change again.  And the global __mbtowc and __wctomb
pointers, too.  It's definitely not a simple task.

But, as for this patch, including the entire locale.h definitions just
to get a single type, which neither is used nor even exists, sounds a
bit too much to me.  After all, SUSv4 only states

  The <strings.h> header shall define the locale_t type as described
  in <locale.h>.

It doesn't say that it's supposed to pull in all of locale.h.

> Anyway, not much of a reason to fret about, at least not now :)

Cool :)


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat