apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lucian Adrian Grijincu" <lucian.griji...@gmail.com>
Subject Re: freezing 1.3 tonight
Date Fri, 02 May 2008 03:12:04 GMT
On Fri, May 2, 2008 at 5:34 AM, Roy T. Fielding <fielding@gbiv.com> wrote:
> On May 1, 2008, at 4:44 PM, Jim Jagielski wrote:
>
>
> > On Thu, May 01, 2008 at 04:18:32PM -0700, Roy T. Fielding wrote:
> >
> > > On May 1, 2008, at 3:33 PM, William A. Rowe, Jr. wrote:
> > >
> > > > Christopher Key wrote:
> > > >
> > > > >
> > > > > >
> > > > > >
> > > > > I'm not sure whether this has been covered already, and whether it
> > > > > needs to go in during a major release, but is there any chance of
> > > > > adding apr_int8_t and apr_uint8_t typedefs?
> > > > >
> > > >
> > >
> > > Why?  The type char is defined by the C standard to be an 8bit signed
> > > integer.
> > >
> >
> > Huh? 'char' may or may not be signed, the spec doesn't specify which,
> > except for the condition that if a "real" character is stored
> > in 'char' then that value is unsigned. But if I store, for example,
> > 0xfb in there, (and 0xfb isn't a "real" character), then whether
> > the value of that char is positive or negative (and thus, whether
> > signed) is impl dependent.
> >
> > The 'signed' qualifier is redundant for all types except 'char'
> >
>
>  Er, except that compiler implementations since K&R1 do implement
>  char as signed because that's how the PDP-11 worked.

ANSI C changed the way type promotions occur.
K&R is "unsigned preserving" - any operands of type char or short are
converted to int; if either operand is unsigned, the other is
converted to unsigned and that is the type
of the result.
ANSI C is "value preserving" - A char, a short int, or an int
bit-field, or their signed or unsigned varieties, or an enumeration
type,
may be used in an expression wherever an int or unsigned int may be
used. If an int can represent all
the values of the original type, the value is converted to an int;
otherwise it is converted to an unsigned
int. These are called the integral promotions.


> Portability
>  would suck otherwise due to integral types (including char) being
>  promoted to a signed integer when used in an integer context.
I don't really get it why it would suck.

test_ansi_kr.c:
#include <stdio.h>
int main()
{
  SIGN char c = 1;
  if ( -1 < c )
    printf("-1 is less than 1: ANSI semantics\n");
  else
    printf("-1 NOT less than 1: K&R semantics\n");
  return 0;
}


Makefile:
CFLAGS+=-Wall -g
all:test_ansi_kr.c
        $(CC) $(CFLAGS) -DSIGN=unsigned $< -o unsigned
        $(CC) $(CFLAGS) -DSIGN=signed $< -o signed
        $(CC) $(CFLAGS) -DSIGN= $< -o notsigned

$ ./signed
-1 is less than 1: ANSI semantics
$ ./notsigned
-1 is less than 1: ANSI semantics
$ ./unsigned
-1 is less than 1: ANSI semantics



The comparison yields different results if you change "char" with
"int", ofcourse.
$ ./unsigned
-1 NOT less than (unsigned) 1
$ ./signed
-1 is less than (signed) 1
$ ./notsigned
-1 is less than (notsigned) 1

-- 
Lucian

Mime
View raw message