> Date: Tue, 22 May 2001 21:41:11 -0400 (EDT)
> From: Keith Bostic <[EMAIL PROTECTED]>
> >> 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.
