svn commit: r235672 - in projects/arm_eabi/sys: amd64/include i386/include ia64/include mips/include pc98/include powerpc/include sparc64/include x86/include

[Bruce Evans]

On Sun, 3 Jun 2012, Andrew Turner wrote:

> On Sun, 20 May 2012 18:58:12 +1000 (EST)
> Bruce Evans <brde at optusnet.com.au> wrote:
>
>> On Sat, 19 May 2012, Andrew Turner wrote:
>>
>>> Log:
>>>  Fix wchar support in the not ARM case.
>>>
>>>   * Add machine/_wchar.h to define WCHAR_{MIN,MAX} and include it
>>> from machine/_stdint.h, it is already in wchar.h.
>>
>> This adds 2 layers of include pessimizations to x86, though only 1
>> layer to other arches.  The pessimization is most noticeable over
>> nfs, where the RPCs for reopening include files can take 10-100 times
>> longer than actually reading and parsing of the files for small files.
>>
>> This has some style bugs.
>>
>>>   * Add the typedef for __wchar_t to machine/_types.h.
>>
>> The limits should be defined (with leading underscores) here too, so
>> that no new includes are needed.
>
> How about the attached patch? It:
> * Removes machine/_wchar.h.

I think this is for the non-project version that doesn't have
machine/_wchar.h.  I forget some of the details of that.

> * Moves the __wchar_t typedef to machine/_types.h.
> * Adds __WCHAR_MIN and __WCHAR_MAX to machine/_types.h and uses them where required.
>
> This is against head and only for sparc64. I will do the same on the
> other architectures.

% Index: include/wchar.h
% ...

OK.

% Index: sys/sparc64/include/_stdint.h
% ===================================================================
% --- sys/sparc64/include/_stdint.h	(revision 234300)
% +++ sys/sparc64/include/_stdint.h	(working copy)
% @@ -151,8 +151,8 @@
% 
%  #ifndef WCHAR_MIN /* Also possibly defined in <wchar.h> */
%  /* Limits of wchar_t. */
% -#define	WCHAR_MIN	INT32_MIN
% -#define	WCHAR_MAX	INT32_MAX
% +#define	WCHAR_MIN	__WCHAR_MIN
% +#define	WCHAR_MAX	__WCHAR_MIN
%  #endif

I hope this can be moved up to sys/stdint.h.

The ifdef is bogus, since it only breaks detection of bugs if the macros
are defined (lexically) differently.  Its comment is not quite right,
since the macros are always defined in <wchar.h>.  What it is trying to
say is that both definitions would be visible if <stdint.h> and <wchar.h>
are both included and we didn't bogusly ifdef them.

In fact, we are hiding bugs with the ifdefs.  The macros are defined
as INT_MIN/MAX in <wchar.h> but as INT32_MIN/MAX in <machine/stdint.h>
all versions of FreeBSD that I checked.  It's interesting that FreeBSD
didn't have them anywhere until 2003, so they weren't in FreeBSD[3-4].

% 
%  /* Limits of wint_t. */

WINT_* doesn't need the same treatment eventually like I said in my
previous reply, since it is not required in <wchar.h>.  There is no
benefit to moving it like the above.  There is on a similar, but smaller
problem for wint_t.

% Index: sys/sparc64/include/_types.h
% ===================================================================
% --- sys/sparc64/include/_types.h	(revision 234300)
% +++ sys/sparc64/include/_types.h	(working copy)
% @@ -92,7 +92,11 @@
%  typedef	__uint64_t	__vm_paddr_t;
%  typedef	__uint64_t	__vm_pindex_t;
%  typedef	__uint64_t	__vm_size_t;
% +typedef	int		__wchar_t;

Shouldn't it be __ct_rune_t?  Oops, that is not in scope.

I think you should declare it as __int32_t, and similarly for the macros.
I don't really like that, and originally I tried to use basic types
wherever possibly in <machine>, but now almost everything in at least
<machine/_types.h> is declared using a derived integral type.  The
main exception is clock_t, and it is extremely broken.  I changed it
long ago on i386 from u_int to u_long to prepare for natural expansion
with 64-bit longs, but it has rotted to become even smaller than u_int
on most arches:
- arm: __uint32_t
- ia32: __int32_t
- mips: __int32_t
- powerpc: __uint32_t
- sparc64: __int32_t
- x86::amd64: __int32_t (requires an ifdef tangle to properly break it)
- x86::i386: unsigned long (causes minor ABI problems; not rotted)

% 
% +#define	__WCHAR_MIN	__INT_MIN
% +#define	__WCHAR_MAX	__INT_MAX
% +

There are no macros for the limits of rune_t, and they might not apply
anyway (see below), so rawer type-related info like this is correct here.

%  /*
%   * Unusual type definitions.
%   */
% Index: sys/sys/_types.h
% ===================================================================
% --- sys/sys/_types.h	(revision 234300)
% +++ sys/sys/_types.h	(working copy)
% @@ -87,7 +87,6 @@
%   */
%  typedef	int		__ct_rune_t;	/* arg type for ctype funcs */
%  typedef	__ct_rune_t	__rune_t;	/* rune_t (see above) */
% -typedef	__ct_rune_t	__wchar_t;	/* wchar_t (see above) */

"above" still describes wchar_t and has a strict requirement:

@ * NOTE: rune_t is not covered by ANSI nor other standards, and should not
@ * be instantiated outside of lib/libc/locale.  Use wchar_t.  wchar_t and
@ * rune_t must be the same type.  Also, wint_t must be no narrower than
            ^^^^
@ * wchar_t, and should be able to hold all members of the largest
@ * character set plus one extra value (WEOF), and must be at least 16 bits.

If you are changing wchar_t to either larger or smaller, then you need
to at least fix the comment.  Changing wchar_t seems to be hard, since
apart from ABI problems, someone may have actually read this comment
and used wchar_t where they really want rune_t.  If this comment is
correct, wchar_t can't be made much smaller without breaking rune_t
for other uses, and if it is enlarged then rune_t must be enlarged to
match, giving more ABI problems.

C99 requires WCHAR_MIN/MAX to be the min/max values representable by
wchar_t, but doesn't require wchar_t to be as small as possible.

%  typedef	__ct_rune_t	__wint_t;	/* wint_t (see above) */
% 
%  typedef	__uint32_t	__dev_t;	/* device number */

Bruce