This is the mail archive of the mailing list for the newlib project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 64bit] ssize_t

On 02/20/2013 04:17 PM, Corinna Vinschen wrote:
On Feb 20 16:08, Ralf Corsepius wrote:
On 02/20/2013 03:14 PM, Corinna Vinschen wrote:
Hi Yaakov,

On Feb 20 03:23, Yaakov (Cygwin/X) wrote:
I just discovered an issue resulting from this commit:

2002-06-27 Jeff Johnston <jjohnstn@...>

         * libc/include/sys/_types.h: Define _ssize_t as int if int is
         32-bits, otherwise define it as long.

On x86_64-cygwin (as on Linux), int is still 32 bits, but size_t is a
64bit unsigned long and ssize_t should be as large but signed.
Possible patch for newlib attached; corresponding patches for
cygwin-64bit-branch on cygwin-patches@.

Thanks for the patch. I'm just wondering if ssize_t shouldn't ideally be based on size_t, at least when using GCC. GCC has a predefined __SIZEOF_SIZE_T__ macro.

What I'm thinking of is something like

#ifndef __ssize_t_defined
# ifdef __SIZEOF_SIZE_T__
#  if defined (__SIZEOF_INT__) && __SIZEOF_SIZE_T__ == __SIZEOF_INT__
typedef int ssize_t;
#  else
typedef long ssize_t
#  endif
# elif defined(__INT_MAX__) && defined(__LONG_MAX__) && __LONG_MAX__ == __INT_MAX__
typedef int _ssize_t;
# else
typedef long _ssize_t;
# endif

Does that make sense?

GCC requires exact symmetry of types between ssize_t and size_t. I.e. checking for sizes of types is not sufficient for [s]size_t.

Do you have a code suggestion then?

Unfortunately no.

So far, the best I have been able to come up with for RTEMS, was a pretty unpleasant, error prone and lacking generality preprocessor cascade:

ATM, it looks like this:
+++ newlib-1.20.0/newlib/libc/sys/rtems/machine/_types.h 2012-10-15 10:31:19.635621334 +0200
@@ -13,7 +13,7 @@
* could be applied here.

-#if defined(__i386__) || defined(__m32r__) || defined(__h8300__) || defined(__arm__) || defined(__bfin__) || defined(__m68k__)
+#if defined(__i386__) || defined(__m32r__) || defined(__h8300__) || (defined(__arm__) && !defined(__ARM_EABI__)) || defined(__bfin__) || define
#if defined(__H8300__)
typedef signed int _ssize_t;
@@ -23,7 +23,8 @@
#elif defined(__sparc__) && defined(__LP64__)
typedef long signed int _ssize_t;
#define __ssize_t_defined 1
-#elif defined(__AVR__) || defined(__lm32__) || defined(__m32c__) || defined(__mips__) || defined(__moxie__) || defined(__PPC__) || defined(__sp
+#elif defined(__AVR__) || defined(__lm32__) || defined(__m32c__) || defined(__mips__) || defined(__moxie__) || defined(__PPC__) || defined(__sp
+ || defined(__v850__) || defined(__v851__)
typedef signed int _ssize_t;
#define __ssize_t_defined 1

 GCC doesn't define ssize_t
by itself,
Right, but GCC (IIRC, since 4.4) defines size_t (__SIZE_T_TYPE__) and also comes with pretty aggressive fprintf-format strings checks related to [s]size_t.

That said, IMO, in an ideal world, GCC also would define a corresponding __SSIZE_T_TYPE__.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]