[klibc] ssize_t (was Re: klibc 2.0~rc3-1 ./. mksh 40.9.20120414-2)

[Thorsten Glaser]

Dixi quod…

>The ssize_t prototype is bogus at least on s390:
>../../shf.c:453:3: warning: format '%zd' expects argument of type 'signed size_t', but argument 4 has type 'ssize_t' [-Wformat]

And cris:

‣ klibc.git/usr/include/bits32/bitsize/stddef.h

    9 #if defined(__s390__) || defined(__cris__)
   10 typedef unsigned long size_t;
   11 #else
   12 typedef unsigned int size_t;
   13 #endif
   14
   15 #define _PTRDIFF_T
   16 typedef signed int ptrdiff_t;

‣ klibc.git/usr/include/sys/types.h

   12 #define _SSIZE_T
   13 typedef ptrdiff_t ssize_t;

Combined, these two definitions make the problem.

The fix applied to MirBSD, dietlibc and Android bionic libc is
to rely on GCC’s definitions for size_t, and hack that into an
ssize_t definition:

‣ mircvs://src/sys/sys/types.h

  116 #if !defined(_GCC_SIZE_T)
  117 #define _GCC_SIZE_T
  118 typedef __SIZE_TYPE__   size_t;
  119 #endif
  120
  121 /* e-eeeevil kludge, but apparently works */
  122 #define unsigned        signed
  123 typedef __SIZE_TYPE__   ssize_t;
  124 #undef unsigned

Something like this would also work:

	typedef __SIZE_TYPE__ size_t;
	#define unsigned /* nothing */
	typedef signed __SIZE_TYPE__ ssize_t;
	#undef unsigned

So far, the code from above MirBSD header has never been a problem
though, as GCC is _very_ picky about its type definitions, such as
size_t and wchar_t:

‣ mircvs://gcc/gcc/config/mirbsd.h

  135 #define WCHAR_TYPE "short unsigned int"
  141 #define WINT_TYPE "unsigned int"
  144 #define SIZE_TYPE "long unsigned int"
  147 #define PTRDIFF_TYPE "long int"

Even changing the order to, say, "unsigned short int" for WCHAR_TYPE,
led to errors later on, so this is pretty constrained.


If you want, I can prepare and submit a klibc patch to use GCC’s
definitions similar to what I’ve done for bionic and dietlibc.

bye,
//mirabilos
-- 
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh