Re: "'char' type is unsigned" seems to be broken
Re: "'char' type is unsigned" seems to be broken
- Subject: Re: "'char' type is unsigned" seems to be broken
- From: David Leimbach <email@hidden>
- Date: Tue, 10 May 2005 18:01:37 -0700
On 5/10/05, email@hidden <email@hidden> wrote:
> David Leimbach wrote:
>
> >On 5/10/05, Clark Cox <email@hidden> wrote:
> >
> >
> >>On 5/9/05, Brian Barnes <email@hidden> wrote:
> >>
> >>
> >>>Turning on "'char' type is unsigned" and running this code:
> >>>
> >>> char txt[256];
> >>> unsigned char txt2[256];
> >>>
> >>> strcpy(txt,"abc");
> >>> strcpy(txt2,"abc");
> >>>
> >>>gets you:
> >>>
> >>>warning: pointer targets in passing argument 1 of 'strcpy' differ in
> >>>signedness
> >>>
> >>>For the first line.
> >>>
> >>>"-funsigned-char" is in the compile arguments. Once again, I'm using
> >>>-fast, this might be breaking it.
> >>>
> >>>
> >>Though the message is a bit off, I'd argue that this is actually
> >>correct. Even if 'char' is unsigned, it is still a type that is
> >>distinct from 'unsigned char'. 'unsigned char*' is not implicitly
> >>convert-able to 'char*'. In fact, the following code:
> >>
> >>
> >
> >Right and in the C standard "char", "unsigned char" and "signed char"
> >are distinct types.
> >
> >Char is specified to behave in an implementation defined way.
> >
> >"int" and "signed int", for example, are synonyms in the C standard
> >and do not require such warnings.
> >
> >The compiler flag just sets what the implementation does for "char"
> >but doesn't change the semantics of the declaration "char" vs "signed
> >char" or "unsigned char".
> >
> Alright, that sounds reasonable. I suggest a better naming for this, as
> I assumed (wrongly) that it was replacing all 'char' types with
> 'unsigned char', instead of just dealing with how the compiler handles
> the math.
Well if you read the documentation it says:
[from the gcc man page]
-funsigned-char
Let the type "char" be unsigned, like "unsigned char".
Each kind of machine has a default for what "char" should be. It
is either like "unsigned char" by default or like "signed char" by
default.
Ideally, a portable program should always use "signed char" or
"unsigned char" when it depends on the signedness of an object.
But many programs have been written to use plain "char" and expect
it to be signed, or expect it to be unsigned, depending on the
machines they were written for. This option, and its inverse, let
you make such a program work with the opposite default.
The type "char" is always a distinct type from each of "signed
char" or "unsigned char", even though its behavior is always just
like one of those two.
So I think it does a reasonable job of explaining the situation.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden