Re: wctomb dumps core on invalid input

[Bruno Haible <haible at ilog dot fr>]

Ulrich Drepper writes:
> Bruno Haible <haible@ilog.fr> writes:
> 
> > According to SUSV2, "wctomb() returns -1 if the value of wchar does not
> > correspond to a valid character". This is not what glibc 2.2 does. Here
> > is a test program.
> > 
> > ===========================================
> > #include <wchar.h>
> > #include <locale.h>
> > 
> > int main ()
> > {
> >   char buf[10];
> >   wchar_t wc = 0xdeadbeef;
> 
> There's a difference.  The standard text refers to the character in
> the multibyte encoding.  If there is no equivalent to the wide
> character -1 is returned.

OK, then let's take a similar function where SUSV2 is clearer: wcstombs.
It lists:

   ERRORS
      [EILSEQ]
         A wide-character code does not correspond to a valid character.

Here is the test program for it. It dumps core as well with glibc-2.2.

=================================================================
#include <stdlib.h>
#include <locale.h>

int main ()
{
  wchar_t wstr[2] = { 0xdeadbeef, 0 };
  char buf[10];
  setlocale(LC_ALL, "de_DE.UTF-8");
  return wcstombs(buf, wstr, sizeof(buf)) >= 0;
}
=================================================================

> A value like 0xdeadbeef for a wchar_t is completely impossible to get
> since no module can produce it.  The assumption that values of wchar_t
> are <= 0x7fffffff must always be met.

Nevertheless it is not acceptable for glibc to dump core on invalid
numerical or textual input. None of close(-3), sqrt(-163), atoi("foo")
do that.

Bruno