apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: apr_uint8_t and apr_int8_t?
Date Thu, 29 Jun 2006 02:04:38 GMT
Mike Duigou wrote:
> A patch to add apr_uint8_t and apr_int8_t to apr.h is attached. It also 
> ensures that CHAR_BIT is 8 bits (it normally is) and that short_value 
> and long_value are defined.

I normally just lurk here but this issue has caught my attention
as I recently implemented the same thing in C++ and gained some
insight into the gotchas behind these seemingly trivial typedefs.
I hope you'll find it helpful.

First, char may be an unsigned type so apr_int8_t should be an
alias for signed char in that case.

Second, if APR headers are intended to be used in C++ programs
(I don't know if that's possible or desirable), it would be a
good idea to define apr_int8_t to the same type as int8_t in
<stdint.h> and not simply to signed char unconditionally. Doing
otherwise will prevent the two from being interchangeable and
lead to compilation or linker errors in programs that mix and
match them.

Martin

> 
> Mike
> 
> William A. Rowe, Jr. wrote:
> 
>> I can definitely see your point.  Although it's not the highest priority,
>> we would certainly consider a patch to effect this behavior.
>>
>> Yours,
>>
>> Bill
>>
>> Mike Duigou wrote:
>>
>>> I'm motivated to ask to this for wire protocols which are defined 
>>> with specific bit sizes. char and unsigned char are not defined to be 
>>> *exactly* 8 bits and are apparently not 8 bits in some esoteric 
>>> environments.
>>>
>>> The C standard 5.2.4.2.1 requires that char and unsigned char be *at 
>>> least* 8 bits but does not fix a value. So assuming that UCHAR_MAX is 
>>> 255 is just as unwise as assuming that UINT_MAX is 65535 or 4294967295.
>>>
>>> This request is also partially for completeness with the other bit 
>>> sized scalar typedefs.
>>>
>>> Mike
>>>
>>> William A. Rowe, Jr. wrote:
>>>
>>>> Can you give us any example where signed char, unsigned char don't
>>>> fit the bill?
>>>>
>>>> Bill
>>>>
>>>> Mike Duigou wrote:
>>>>
>>>>> Hi!
>>>>>
>>>>> Would it be possible to add definitions for apr_uint8_t and 
>>>>> apr_int8_t to apr.h? This appears to have been previously requested 
>>>>> in 2001 
>>>>> (http://mail-archives.apache.org/mod_mbox/apr-dev/200105.mbox/%3CJLEGKKNELMHCJPNMOKHOGELPDOAA.striker@samba-tng.org%3E)

>>>>> but I don't see any response indicating why the change was never made.
>>>>>
>>>>> Mike
>>>>>
>>>>> .
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
> 
> 
> ------------------------------------------------------------------------
> 
> Index: include/apr.h.in
> ===================================================================
> --- include/apr.h.in	(revision 417882)
> +++ include/apr.h.in	(working copy)
> @@ -254,8 +254,11 @@
>  
>  /* Typedefs that APR needs. */
>  
> -typedef  unsigned char           apr_byte_t;
> +typedef  unsigned @byte_value@   apr_byte_t;
>  
> +typedef  @byte_value@            apr_int8_t;
> +typedef  unsigned @byte_value@   apr_uint8_t;
> +
>  typedef  @short_value@           apr_int16_t;
>  typedef  unsigned @short_value@  apr_uint16_t;
>                                                 
> Index: configure.in
> ===================================================================
> --- configure.in	(revision 417882)
> +++ configure.in	(working copy)
> @@ -1098,6 +1098,21 @@
>  fi
>  
>  dnl ----------------------------- Checks for standard typedefs
> +echo "${nl}Checking for Standard Typedefs..."
> +
> +dnl Check that CHAR_BIT is an octect (8-bits) in length.
> +AC_DEFUN([AC_C_CHAR_BIT_OCTET],
> +[AC_CACHE_CHECK([if CHAR_BIT is octet on this platform], ac_cv_decl_char_bit_octet,
> +[AC_EGREP_CPP(octet,
> +[#ifdef HAVE_LIMITS_H
> +#include <limits.h>
> +#endif
> +#if CHAR_BIT == 8
> +octet
> +#endif], ac_cv_decl_char_bit_octet=yes, ac_cv_decl_char_bit_octet=no)
> +])
> +])
> +
>  AC_TYPE_OFF_T
>  AC_TYPE_PID_T
>  AC_TYPE_SIZE_T
> @@ -1119,18 +1134,34 @@
>  fi
>  
>  dnl Checks for integer size
> +AC_C_CHAR_BIT_OCTET
>  AC_CHECK_SIZEOF(char, 1)
>  AC_CHECK_SIZEOF(int, 4)
>  AC_CHECK_SIZEOF(long, 4)
>  AC_CHECK_SIZEOF(short, 2)
>  AC_CHECK_SIZEOF(long long, 8)
>  
> +if test "$ac_cv_decl_char_bit_octet" = "yes"; then
> +    byte_value=char
> +else
> +    # no known value for 8 bit type
> +    AC_ERROR([could not detect a 8-bit integer type])
> +fi
> +
>  if test "$ac_cv_sizeof_short" = "2"; then
>      short_value=short
> +else
> +    # no known value for 16 bit type
> +    AC_ERROR([could not detect a 16-bit integer type])
>  fi
> +
>  if test "$ac_cv_sizeof_int" = "4"; then
>      int_value=int
> +else
> +    # no known value for 32 bit type
> +    AC_ERROR([could not detect a 32-bit integer type])
>  fi
> +
>  # Now we need to find what apr_int64_t (sizeof == 8) will be.
>  # The first match is our preference.
>  if test "$ac_cv_sizeof_int" = "8"; then
> @@ -1360,6 +1391,7 @@
>  esac
>  
>  AC_SUBST(voidp_size)
> +AC_SUBST(byte_value)
>  AC_SUBST(short_value)
>  AC_SUBST(int_value)
>  AC_SUBST(long_value)


Mime
View raw message