Re: feature suggestion: how to figure out specific size types.

[Paul Eggert]

> Date: Tue, 22 May 2001 21:41:11 -0400 (EDT)
> From: Keith Bostic <address@hidden>

> >> Another example are applications that are written (correctly)
> >> to use ssize_t.  If the system has a size_t, but not a ssize_t,
> >> to what type do you typedef the ssize_t?
> >
> > Most people use AC_CHECK_TYPE(ssize_t, int).
> 
> Yes, that's what I used to use as well.
> 
> Bless their furry little hearts, Win/64 has a 64-bit size_t,
> no ssize_t, and a 32-bit int.

Yes, sorry, I forgot about Windows 64.  If it's easy to come up with a
macro that works for that platform too, that's OK, but if it's at all
tricky then I wouldn't bother, as that is a low-priority platform.
Quoting from the GNU coding standards
<http://www.gnu.org/prep/standards_27.html>:

   Don't make any effort to cater to the possibility that long will be
   smaller than predefined types like size_t. For example, the
   following code is ok:

      printf ("size = %lu\n", (unsigned long) sizeof array);
      printf ("diff = %ld\n", (long) (pointer2 - pointer1));

   1989 Standard C requires this to work, and we know of only one
   counterexample: 64-bit programs on Microsoft Windows IA-64. We will
   leave it to those who want to port GNU programs to that environment
   to figure out how to do it.

   Predefined file-size types like off_t are an exception: they are
   longer than long on many platforms, so code like the above won't
   work with them. One way to print an off_t value portably is to print
   its digits yourself, one by one.


Unless I'm missing something this issue with ssize_t is indepedent of
your other suggestion, which was to add support to autoconf for
uint16_t etc., and which is the more important issue for the GNU project.