Thread overview
Error on Linux PPC - unsigned char
Jan 17, 2005
David Friedman
Jan 17, 2005
Marco
January 16, 2005
Background:
The "char" type on Linux for PowerPC is unsigned...
(they are signed on the X86, and also on Mac OS X)
If you want it signed, you must say "signed char"

So when building on e.g. Yellow Dog Linux there
is a -fsigned-char flag added to CFLAGS, to make
the code behave the same as it does on Linux X86.

http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/C-Dialect-Options.html#index-fsigned_002dchar-111

Unfortunately, GDC does *not* accept this flag:
> command line option "-fsigned-char" is valid
> for C/C++/ObjC/ObjC++ but not for D

When not adding this flag, it gives a few errors
later on - when trying to build the Phobos library.
(the error output from make is in the attachment)

Hopefully this restriction on GDC can be lifted ?

--anders




January 17, 2005
Anders F Björklund wrote:
> Background:
> The "char" type on Linux for PowerPC is unsigned...
> (they are signed on the X86, and also on Mac OS X)
> If you want it signed, you must say "signed char"
> 
> So when building on e.g. Yellow Dog Linux there
> is a -fsigned-char flag added to CFLAGS, to make
> the code behave the same as it does on Linux X86.
> 
> http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/C-Dialect-Options.html#index-fsigned_002dchar-111 
> 
> 
> Unfortunately, GDC does *not* accept this flag:
> 
>> command line option "-fsigned-char" is valid
>> for C/C++/ObjC/ObjC++ but not for D
> 
> 
> When not adding this flag, it gives a few errors
> later on - when trying to build the Phobos library.
> (the error output from make is in the attachment)
> 
> Hopefully this restriction on GDC can be lifted ?
> 
> --anders
> 
> 
> 
> ------------------------------------------------------------------------
> 
> gdc -o std/loader.o -g -frelease -O2  -nostdinc -I ../gcc-3.4.3/gcc/d/phobos -I ../gcc-3.4.3/gcc/d/phobos/internal/gc -c ../gcc-3.4.3/gcc/d/phobos/std/loader.d
> ../gcc-3.4.3/gcc/d/phobos/std/loader.d:413: function gcc.builtins.__builtin_strlen (ubyte*) does not match argument types (char*)
> ../gcc-3.4.3/gcc/d/phobos/std/loader.d:413: cannot implicitly convert expression err of type char* to ubyte*
> make: *** [std/loader.o] Error 1
> gdc -o internal/dmain2.o -g -frelease -O2  -nostdinc -I ../gcc-3.4.3/gcc/d/phobos -I ../gcc-3.4.3/gcc/d/phobos/internal/gc -c ../gcc-3.4.3/gcc/d/phobos/internal/dmain2.d
> ../gcc-3.4.3/gcc/d/phobos/internal/dmain2.d:95: function gcc.builtins.__builtin_strlen (ubyte*) does not match argument types (char*)
> ../gcc-3.4.3/gcc/d/phobos/internal/dmain2.d:95: cannot implicitly convert expression argv[i] of type char* to ubyte*
> make: *** [internal/dmain2.o] Error 1
<snip>

I should be able to fix this so that it won't be necessary to specify the flag at all.  Ideally, it shouldn't be needed because D specifies that characters are unsigned.

David
January 17, 2005
In article <csdtua$1uf2$1@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>
>This is a multi-part message in MIME format.
>--------------050202030008060200050005
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit
>
>Background:
>The "char" type on Linux for PowerPC is unsigned...
>(they are signed on the X86, and also on Mac OS X)
>If you want it signed, you must say "signed char"
>
>So when building on e.g. Yellow Dog Linux there
>is a -fsigned-char flag added to CFLAGS, to make
>the code behave the same as it does on Linux X86.
>

I think using default char is just bad practice. You either want an 8 bit
integer (signed) or an 8 bit character (unsigned) variable.


January 17, 2005
David Friedman wrote:

> I should be able to fix this so that it won't be necessary to specify the flag at all.  Ideally, it shouldn't be needed because D specifies that characters are unsigned.

If you could make it silently accept the flag too, that'd be awesome!
(since it's in the default %{optflags} for RPM, it would be easier...)

It shouldn't be needed for D code, just for the C glue (and GCC is OK)
--anders
January 17, 2005
Marco wrote:

> I think using default char is just bad practice. You either want an 8 bit
> integer (signed) or an 8 bit character (unsigned) variable. 

It's bad in the same way that the default int is bad,
you either want a short (16-bit) or a long (32-bit)...

In current practice, char's are signed and int's 32-bit
In theory, it shouldn't matter which - or be specified.


Fortunately, all D integers have specified signs and widths.
It's just strings and booleans and reals that vary in size... ;-)

--anders