«

When compiling with -Wall I always get the warning
../dictionary.c:156: warning: pointer targets in passing argument 1 to strcmp differ in signedness

I alwyays use unsigned chars for my text data, since there are no negative character, just character
codes. Problem is, strcmp expects chars, and gcc thinks that chars are signed by default, what is
all correct of course, but annoying.

Is there any way to convince it to avoid putting this warning?


Thanks

jacob navia <> writes:

> ./dictionary.c:156: warning: pointer targets in passing argument 1 to strcmp differ in signedness
[...]
> Is there any way to convince it to avoid putting this warning?

-Wno-pointer-sign
--
"When I have to rely on inadequacy, I prefer it to be my own."
--Richard Heathfield

Ben Pfaff a écrit :
> jacob navia <> writes:
>
>> ./dictionary.c:156: warning: pointer targets in passing argument 1 to strcmp differ in signedness
> [...]
>> Is there any way to convince it to avoid putting this warning?
>
> -Wno-pointer-sign

OK, that worked, thanks

jacob navia wrote:
> When compiling with -Wall I always get the warning
> ../dictionary.c:156: warning: pointer targets in passing argument 1 to
> strcmp differ in signedness
>
> I alwyays use unsigned chars for my text data, since there are no
> negative character, just character codes. Problem is, strcmp expects
> chars, and gcc thinks that chars are signed by default, what is
> all correct of course, but annoying.

How do you cope with string literals?

--
Ian Collins

jacob navia wrote:
> When compiling with -Wall I always get the warning
> ./dictionary.c:156: warning: pointer targets in passing argument 1 to
> strcmp differ in signedness
>
> I alwyays use unsigned chars for my text data, since there are no
> negative character, just character codes. Problem is, strcmp expects
> chars, and gcc thinks that chars are signed by default, what is
> all correct of course, but annoying.
>
> Is there any way to convince it to avoid putting this warning?

Use char.

"If you lie to the compiler, it will get its revenge."
-- Henry Spencer

--
Eric Sosman
lid

Eric Sosman a écrit :
> jacob navia wrote:
>> When compiling with -Wall I always get the warning
>> ./dictionary.c:156: warning: pointer targets in passing argument 1 to
>> strcmp differ in signedness
>>
>> I alwyays use unsigned chars for my text data, since there are no
>> negative character, just character codes. Problem is, strcmp expects
>> chars, and gcc thinks that chars are signed by default, what is
>> all correct of course, but annoying.
>>
>> Is there any way to convince it to avoid putting this warning?
>
> Use char.
>
> "If you lie to the compiler, it will get its revenge."
> -- Henry Spencer
>

I do not want to have negative characters!
They are NOT integers, that is why they are UNSIGNED.

If you limit yourself to ASCII, it could be OK, but I do not want just
ASCII.

jacob navia wrote:
> Eric Sosman a écrit :
>> jacob navia wrote:
>>> When compiling with -Wall I always get the warning
>>> ./dictionary.c:156: warning: pointer targets in passing argument 1 to
>>> strcmp differ in signedness
>>>
>>> I alwyays use unsigned chars for my text data, since there are no
>>> negative character, just character codes. Problem is, strcmp expects
>>> chars, and gcc thinks that chars are signed by default, what is
>>> all correct of course, but annoying.
>>>
>>> Is there any way to convince it to avoid putting this warning?
>>
>> Use char.
>>
>> "If you lie to the compiler, it will get its revenge."
>> -- Henry Spencer
>>
>
> I do not want to have negative characters!
> They are NOT integers, that is why they are UNSIGNED.
>
> If you limit yourself to ASCII, it could be OK, but I do not want just
> ASCII.

So how do you handle string literals?

How do you manage warnings form other compilers? You are producing
non-portable code.

--
Ian Collins

Richard Heathfield a écrit :
> In <hdkpl5$8aq$>, jacob navia wrote:
>
> <snip>
>
>> I do not want to have negative characters!
>> They are NOT integers, that is why they are UNSIGNED.
>
> Um, signed or unsigned, characters are integers whether you like it or
> not. Presumably you mean that you are thinking of them as text glyphs
> rather than as integers (which is fine, by the way - lots of us do
> that some or all of the time). I don't see why you think making them
> unsigned stops them from being integers.
>
> <snip>
>

They are integers, from zero to 2^CHAR_BIT.

I.e. they are non negative integer codes.

Since when manipulating bits I need to avoid sign extensions, I used in the
bit string package unsigned integers throughout. Converting signed chars into
unsigned integers can produce all kinds of nonsense.

I standardized into unsigned char throughout the container library. There
is NO system that I know of that would have a different pointer size
or characteristics for signed or unsigned chars!

In article <hdkpl5$8aq$>, jacob navia <> wrote:
>
>I do not want to have negative characters!

Can you give an example of something that doesn't work with plain char
specifically because some characters are negative? I think that can only
happen if you are making bad assumptions.

--
Alan Curry

Alan Curry a écrit :
> In article <hdkpl5$8aq$>, jacob navia <> wrote:
>> I do not want to have negative characters!
>
> Can you give an example of something that doesn't work with plain char
> specifically because some characters are negative? I think that can only
> happen if you are making bad assumptions.
>

I assume characters are codes from one to 255. This is a bad assumption
maybe, in some kind of weird logic when you assign a sign to a character
code.

There is a well established confusion in C between characters (that are
encoded as integers) and integer VALUES.

One of the reasons is that we have "signed" and "unsigned" characters.

I prefer not to use any sign in the characters, and treat 152 as character
code 152 and not as -104. Stupid me, I know.

Besides, when I convert it into a bigger type, I would like to get
152, and not 4294967192.

Of course, when YOU see 4294967192 you think immediately:

Ahhh of course, that is character code 152 that got converted into an int, then casted
to unsigned and got that weird value...

Since size_t is unsigned, converting to unsigned is a fairly common operation.

Or when comparing, I get

warning: "comparison between signed and unsigned".

And MANY other bugs and stuff I do not want to get involved with. Writing software
is difficult enough without having to bother with the sign of characters or the
sex of angels, or the number of demons you can fit in a pin's head.