apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Key <cj...@cam.ac.uk>
Subject Re: freezing 1.3 tonight
Date Fri, 02 May 2008 09:42:14 GMT
Issac Goldstand wrote:
> Jim Jagielski wrote:
>> On Thu, May 01, 2008 at 06:52:58PM -0500, William A. Rowe, Jr. wrote:
>>> Lucian Adrian Grijincu wrote:
>>>> On Fri, May 2, 2008 at 2:18 AM, Roy T. Fielding <fielding@gbiv.com>

>>>> wrote:
>>>>> Why?  The type char is defined by the C standard to be an 8bit 
>>>>> signed integer.
>>>>> The type unsigned char is defined to be an 8bit unsigned integer.  
>>>>> Why would
>>>>> we want to add a bunch of unnecessary casting?
>>>> Not quite: http://home.att.net/~jackklein/c/inttypes.html
>>> That doesn't resolve Roy's question of "why overload signed char and
>>> unsigned char"?
>>> Can anyone point to a platform where int8_t/uint8_t != 
>>> signed/unsigned char?
>>> If so, I agree with the patch.
>> I must have misunderstood the orig request... I thought it was simply
>> creating int8_t/uint8_t to compliment the existing int*_t/uint*_t types
> That's what I read too, and would answer Roy's question as "uniform 
> syntax/readability".  Not a strong reason, but certainly no harm that 
> I can see in it...
Apologies, with the amount of traffic this generated, this request must 
look like I'm trolling!

The reason for wanting the (u)int8 types was primarily for readabilty, 
i.e. to distinguish between whether you are manipulating character data 
or numerical data.  Moreover, there are times where you specifically 
require an 8 bit uint, i.e. 255 + 1 == 0 etc.

If using (u)int8_t is going to break compatibilty on otherwise 
compatible platforms then using it really isn't a good idea.  As in 
practice CHAR_BIT == 8 on almost all platforms, would it be acceptable 
to typedef apr_(u)int8_t as (un)signed char only if CHAR_BIT == 8, and 
leave them undefined otherwise.  The range of supported platforms could 
be further extended by checking for a C99 implementation and then using 
(u)int8_t's if available, before then checking CHAR_BIT == 8 and falling 
back to (un)signed char, or undefined.  I'm not sure if this is 
acceptable according to the APR standards, but would work pretty well.  
It should only break programs that specifically require 8 bit ints on 
platforms that don't provide them, and would give an early, noisy 
failure rather than allowing the program to compile, but then not behave 
correctly.  If CHAR_BIT defined on all platforms that APR supports?

I could of course do this myself in my own headers.  However, 
readability would not be helped by having my_uint8_t's mixed with 
apr_uint16_t's, and declaring apr_uint8_t myself seems like pretty bad 



View raw message