Re: gcc 4 signed vs unsigned char

Keith Thompson ha escrito:
> juanitofoo@xxxxxxxxx writes:
> > Old Wolf ha escrito:
> >> juanitofoo@xxxxxxxxx wrote:
> >> > Hello,
> >> > I've just switched to gcc 4 and I came across a bunch of warnings that
> >> > I can't fix. Example:
> >> >
> >> > #include <stdio.h>
> >> >
> >> > int main()
> >> > {
> >> > signed char *p = "Hola";
> >> >
> >> > return 0;
> >> > }
> >> >
> >> > If I compile that file, I get:
> >> > kk.c: In function 'main':
> >> > kk.c:5: warning: pointer targets in initialization differ in signedness
> >> >
> >> > Only if I remove the signed from the declaration it compiles without
> >> > errors. How can I use the signed or unsigned char?
> >>
> >> You should write code that works just as well whether plain char
> >> is signed or not.
> >>
> >> > I'm using gcc 4.0.1. The reason for asking this is because in one
> >> > program I'm always using int8_t and u_int8_t values, and both of them
> >> > are signed or unsigned, no simply 'char' variables.
> >>
> >> You could avoid the warning with:
> >> signed char *p = (signed char *)"Hola";
> >>
> >> However I can't think of a reason why you would prefer this
> >> to:
> >> char const *p = "Hola";
> >>
> >> Can you post some code that demonstrates why you need to
> >> point to non-const, signed chars?
> >
> > The reason is just that I'm using always int8_t instead of char, is
> > that correct and portable for all platforms? (int8_t is a signed char)
>
> Your problem is simple: you're using int8_t instead of char.
>
> The solution is equally simple: use char.
>
> Is there some reason you're using int8_t when char is more appropriate?

I've always thought that using int8_t would be more portable, but it
seems I was wrong. I'll change my code to use char then :) Thanks for
everything.

.

Relevant Pages

  • Re: Malcolms new book
    ... negative yet you use a signed type which accepts negative values, ... *must* be some special reason for allowing negative length values. ... There are good reasons to use size_t for buffer sizes (mostly ... not prevent passing in a char, it simply requires that the value of the ...
    (comp.lang.c)
  • Re: Malcolms new book
    ... negative yet you use a signed type which accepts negative values, ... *must* be some special reason for allowing negative length values. ... Since a buffer can never have a size less than zero, ... not prevent passing in a char, it simply requires that the value of the ...
    (comp.lang.c)
  • Re: HELP!!
    ... char txtFile; ... getting Segmentation fault here** ... What if malloc() fails and returns a null pointer? ... reasonable implementation, but there's no reason not to avoid malloc ...
    (comp.lang.c)
  • Re: Comments on my code?
    ... value in a char *. ... void *malloc; ... There's simply no good reason not to ... You can still write working archaic code if ...
    (comp.lang.c)
  • JNI: Signedness with GetStringUTFChars() and ReleaseStringUTFChars()
    ... const jbyte *str; ... const char* ... GetStringUTRCharsreturns a ptr to a signed char. ...
    (comp.lang.java.programmer)