autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paul Eggert
Subject: Re: feature suggestion: how to figure out specific size types.
Date: Tue, 22 May 2001 10:40:59 -0700 (PDT)

> From: Keith Bostic <address@hidden>
> Date: Tue, 22 May 2001 11:00:31 -0400 (EDT)
> 
> A feature I would like to see in autoconf is a way to find out
> how to typedef to a specific size on a system.

I would say that any such scheme should mimic the C99 size scheme, as
it can be implemented on pre-C99 compilers and there's no need to
reinvent the wheel.  I know that the Berkeley naming convention
predates C99, but I don't see the need to maintain two naming
conventions in user code, and the C99 naming convention has some minor
technical advantages as described below.

E.g. C code should have this:

   #include <config.h>

   #if HAVE_INTTYPES_H
   # include <inttypes.h>
   #endif

   uint16_t foo;

and config.h should define HAVE_INTTYPES_H if <inttypes.h> exists, and
should define uint16_t only if inttypes.h does not (and only if the
system has a 16-bit unsigned int type, of course).

In my experience, portable code should use <inttypes.h>, not
<stdint.h>.  Both headers are in C99, but <inttypes.h> is more
prevalent in pre-C99 hosts (notably Solaris), and <inttypes.h>
defines a superset of what <stdint.h> defines so there's not much
sense to including <stdint.h>.

Once nice property of the C99 scheme, along with a config.h that
mimics it with #defines, is that user code can write something like
this:

     #ifdef UINT16_MAX
        code that uses uint16_t
     #else
        workaround (possibly less efficient) code that does not use uint16_t
     #endif

This is a bit better than the scheme in the code that you sent, where
"configure" fails if an unsigned 16-bit type is not available.

>       AC_TRY_RUN([main(){exit(sizeof(unsigned short) != 2);}],
>               [db_cv_uint16="unsigned short"],

This code assumes that characters are 8 bits wide.  It's not that hard
to remove the assumption; just use CHAR_BIT.

> If it would be of interest to the maintainers, and you folks would
> tell me what you'd like the interfaces to be, I'd be happy to write
> some macros to do the work and contribute them back.

That would be great.  Here's a possible interface: about an autoconf
macro called AC_INTTYPES, which defines the C macros uint16_t,
UINT16_MAX, etc.  Without thinking about it too much, I guess
AC_INTTYPES should use AC_INCLUDES_DEFAULT(), which in turn defines
HAVE_INTTYPES_H.


> 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).  This relies on the
autoconf 2.50 AC_CHECK_TYPE, which includes unistd.h if available.  I
don't know of any (necessarily old and pre-POSIX) system lacking
ssize_t where 'int' does not work.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]