Re: [patch] unsync between ctype and wctype

2015-07-07 Thread Sebastien Marie 
On Tue, Jul 07, 2015 at 10:37:34AM +0200, Stefan Sperling wrote:
 On Tue, Jul 07, 2015 at 09:25:30AM +0200, Sebastien Marie wrote:
  Hi,
  
  _C_ctype_ (ctype) and _DefaultRuneLocale.rl_runetype (wctype) are
  currently unsynced, resulting regress/lib/libc/locale/check_isw to
  failed.
  
 
 Yes, the C locale should contain only ASCII.
 
 I must have missed this second table when I changed the default locale
 to ASCII from latin1.
 
  Comments ? OK ?
 
 In my opinion we can remove these lines instead of using #if 0.
 

New patch with lines removed.

-- 
Sebastien Marie

Index: locale/runetable.c
===
RCS file: /cvs/src/lib/libc/locale/runetable.c,v
retrieving revision 1.6
diff -u -p -r1.6 runetable.c
--- locale/runetable.c  12 Apr 2015 20:18:41 -  1.6
+++ locale/runetable.c  7 Jul 2015 08:50:33 -
@@ -177,134 +177,6 @@ _RuneLocale _DefaultRuneLocale = {
_CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
_CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
_CTYPE_C,
-   /*80*/  _CTYPE_C, 
-   _CTYPE_C, 
-   _CTYPE_C,
-   _CTYPE_C,
-   _CTYPE_C,
-   _CTYPE_C,
-   _CTYPE_C,
-   _CTYPE_C,
-   /*88*/  _CTYPE_C, 
-   _CTYPE_C, 
-   _CTYPE_C,
-   _CTYPE_C,
-   _CTYPE_C,
-   _CTYPE_C,
-   _CTYPE_C,
-   _CTYPE_C,
-   /*90*/  _CTYPE_C, 
-   _CTYPE_C, 
-   _CTYPE_C,
-   _CTYPE_C,
-   _CTYPE_C,
-   _CTYPE_C,
-   _CTYPE_C,
-   _CTYPE_C,
-   /*98*/  _CTYPE_C, 
-   _CTYPE_C, 
-   _CTYPE_C,
-   _CTYPE_C,
-   _CTYPE_C,
-   _CTYPE_C,
-   _CTYPE_C,
-   _CTYPE_C,
-   /*A0*/  _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   /*A8*/  _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   /*B0*/  _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   /*B8*/  _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   /*C0*/  _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   /*C8*/  _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   /*D0*/  _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
-

Re: [patch] unsync between ctype and wctype

2015-07-07 Thread Stefan Sperling 
On Tue, Jul 07, 2015 at 09:25:30AM +0200, Sebastien Marie wrote:
 Hi,
 
 _C_ctype_ (ctype) and _DefaultRuneLocale.rl_runetype (wctype) are
 currently unsynced, resulting regress/lib/libc/locale/check_isw to
 failed.
 
 The problem is _C_ctype_ (in gen/ctype_.c) and _DefaultRuneLocale (in
 locale/runetable.c) define differently characters class for char = 0x80.
 
 After checking with FreeBSD, NetBSD and DragonFlyBSD: OpenBSD is alone
 to define something different from 0 for char = 0x80 (outside 7bit
 ASCII) in default configuration (which should be C or POSIX).

Yes, the C locale should contain only ASCII.

I must have missed this second table when I changed the default locale
to ASCII from latin1.

 Comments ? OK ?

In my opinion we can remove these lines instead of using #if 0.

 -- 
 Sebastien Marie
 
 Index: locale/runetable.c
 ===
 RCS file: /cvs/src/lib/libc/locale/runetable.c,v
 retrieving revision 1.6
 diff -u -p -r1.6 runetable.c
 --- locale/runetable.c12 Apr 2015 20:18:41 -  1.6
 +++ locale/runetable.c7 Jul 2015 06:39:47 -
 @@ -177,6 +177,7 @@ _RuneLocale _DefaultRuneLocale = {
   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
   _CTYPE_C,
 +#if 0
   /*80*/  _CTYPE_C, 
   _CTYPE_C, 
   _CTYPE_C,
 @@ -305,6 +306,7 @@ _RuneLocale _DefaultRuneLocale = {
   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
   _CTYPE_P|_CTYPE_R|_CTYPE_G|_CTYPE_SW1,
 +#endif
  },
  {0x00,   0x01,   0x02,   0x03,   0x04,   0x05,   0x06,   0x07,
   0x08,   0x09,   0x0a,   0x0b,   0x0c,   0x0d,   0x0e,   0x0f,

Re: [patch] unsync between ctype and wctype

2015-07-07 Thread Todd C. Miller 
On Tue, 07 Jul 2015 10:51:22 +0200, Sebastien Marie wrote:

 New patch with lines removed.

Makes sense.  OK millert@

 - todd

Re: [patch] unsync between ctype and wctype

2015-07-07 Thread Roland Kammerer 
On Tue, Jul 07, 2015 at 09:25:30AM +0200, Sebastien Marie wrote:
 
 Note I am unsure on a point: the array is defined to be _CACHED_RUNES
 (18 = 256) elements in size. Here the initialisation is for 128
 elements.
 
  int tab[256] = {0, 1, 2, ..., 126, 127};
 
 Should the rest of the array be initialised with zero ? or the compiler
 will do it alone ? I have checked NetBSD, FreeBSD and DragonflyBSD: all
 have this construct (array of 256, initialisation with 128 elements).

That is fine, if you partially initialize an array, the rest gets a
default value of 0. A quite common idiom is for example:

int ar[1024] = {0}; /* make all elements zero */

Regards, rck