Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Thu, 15 Feb 2007, Sergei Organov wrote:
>>
>> I agree that if the warning has no true positives, it sucks. The problem
>> is that somehow I doubt it has none. And the reasons for the doubt are:
>
> Why do you harp on "no true positives"?
Because if
Bodo Eggert <[EMAIL PROTECTED]> writes:
> On Fri, 16 Feb 2007, Sergei Organov wrote:
[...]
> I'll say it again: Either the code using unspecified chars is correct, or
> it isn't. If it's correct, neither using with signed nor with unsigned
> chars is a bug and you should not warn at all, and if
Rene Herman <[EMAIL PROTECTED]> writes:
[...]
> Given char's special nature, shouldn't the conclusion of this thread
> have long been simply that gcc needs -Wno-char-pointer-sign? (with
> whatever default, as far as I'm concerned).
I entirely agree that all the char business in C is messy enough t
Bodo Eggert <[EMAIL PROTECTED]> writes:
> On Fri, 16 Feb 2007, Sergei Organov wrote:
>> Bodo Eggert <[EMAIL PROTECTED]> writes:
>> > Sergei Organov <[EMAIL PROTECTED]> wrote:
>> >> Linus Torvalds <[EMAIL PROTECTED]> writes:
>
[...]
>> If we start talking about the C language, my opinion is that it'
On Fri, 16 Feb 2007, Sergei Organov wrote:
> Bodo Eggert <[EMAIL PROTECTED]> writes:
> > Sergei Organov <[EMAIL PROTECTED]> wrote:
> >> Linus Torvalds <[EMAIL PROTECTED]> writes:
> > If you don't code for a specific compiler with specific settings, there is
> > no implementation defining the signe
On Fri, 16 Feb 2007, Sergei Organov wrote:
> Bodo Eggert <[EMAIL PROTECTED]> writes:
> > Sergei Organov <[EMAIL PROTECTED]> wrote:
> >> Linus Torvalds <[EMAIL PROTECTED]> writes:
> [...]
> > Using signed chars for strings is wrong in most countries on earth. It was
> > wrong when the first IBM PC
Bodo Eggert <[EMAIL PROTECTED]> writes:
> Sergei Organov <[EMAIL PROTECTED]> wrote:
>> Linus Torvalds <[EMAIL PROTECTED]> writes:
>
>>> Exactly because "char" *by*definition* is "indeterminate sign" as far as
>>> something like "strlen()" is concerned.
>>
>> Thanks, I now understand that you eith
Bodo Eggert <[EMAIL PROTECTED]> writes:
> Sergei Organov <[EMAIL PROTECTED]> wrote:
>> Linus Torvalds <[EMAIL PROTECTED]> writes:
[...]
> Using signed chars for strings is wrong in most countries on earth. It was
> wrong when the first IBM PC came out in 1981, and creating a compiler in
> 1987 defa
On 02/15/2007 08:02 PM, Linus Torvalds wrote:
Think of it this way: in science, a theory is proven to be bad by a
single undeniable fact just showing that it's wrong.
The same is largely true of a warning. If the warning sometimes
happens for code that is perfectly fine, the warning is bad.
S
On Thu, Feb 15, 2007 at 07:57:05AM -0800, Linus Torvalds wrote:
> I agree that it's "unnecessary code", and in many ways exactly the same
> thing. I just happen to believe that casts tend to be a lot more dangerous
> than extraneous initializations. Casts have this nasty tendency of hiding
> *ot
> From: Linus Torvalds
> Newsgroups: gmane.linux.kernel
> Subject: Re: somebody dropped a (warning) bomb
> Date: Thu, 15 Feb 2007 11:02:32 -0800 (PST)
[]
> Think of it this way: in science, a theory is proven to be bad by a single
> undeniable fact just showing that it'
Sergei Organov <[EMAIL PROTECTED]> wrote:
> Linus Torvalds <[EMAIL PROTECTED]> writes:
>> Exactly because "char" *by*definition* is "indeterminate sign" as far as
>> something like "strlen()" is concerned.
>
> Thanks, I now understand that you either don't see the difference
> between "indetermin
Olivier Galibert <[EMAIL PROTECTED]> writes:
> On Tue, Feb 13, 2007 at 09:06:24PM +0300, Sergei Organov wrote:
>> I agree that making strxxx() family special is not a good idea. So what
>> do we do for a random foo(char*) called with an 'unsigned char*'
>> argument? Silence? Hmmm... It's not immed
On Thu, 15 Feb 2007, Sergei Organov wrote:
>
> I agree that if the warning has no true positives, it sucks. The problem
> is that somehow I doubt it has none. And the reasons for the doubt are:
Why do you harp on "no true positives"?
That's a pointless thing. You can make *any* warning have "t
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Thu, 15 Feb 2007, Sergei Organov wrote:
[...Skip things I agree with...]
>> > But if you have
>> >
>> >unsigned char *mystring;
>> >
>> >len = strlen(mystring);
>> >
>> > then please tell me how to fix that warning without making the code
On Thu, 15 Feb 2007, Sergei Organov wrote:
>
> Yes, there is. There are at least 2 drawbacks. Minor one is
> initialization eating cycles. Major one is that if later I change the
> code and there will appear a pass that by mistake uses those fake value,
> I won't get the warning anymore. The lat
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Tue, 13 Feb 2007, Sergei Organov wrote:
[...]
> BUT (and this is a big but) within the discussion of "strlen()", that is
> no longer true. "strlen()" exists _outside_ of a single particular
> implementation. As such, "implementation-defined" is no l
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Tue, 13 Feb 2007, Sergei Organov wrote:
>>
>> Sorry, what do you do with "variable 'xxx' might be used uninitialized"
>> warning when it's false? Turn it off? Annotate the source? Assign fake
>> initialization value? Change the compiler so that it do
Olivier Galibert <[EMAIL PROTECTED]> writes:
> On Tue, Feb 13, 2007 at 09:06:24PM +0300, Sergei Organov wrote:
[...]
>> May I suggest another definition for a warning being entirely sucks?
>> "The warning is entirely sucks if and only if it never has true
>> positives." In all other cases it's only
On Tue, 13 Feb 2007, Sergei Organov wrote:
>
> Sorry, what do you do with "variable 'xxx' might be used uninitialized"
> warning when it's false? Turn it off? Annotate the source? Assign fake
> initialization value? Change the compiler so that it does "the effort"
> for you? Never encountered fa
On Tue, Feb 13, 2007 at 09:06:24PM +0300, Sergei Organov wrote:
> I agree that making strxxx() family special is not a good idea. So what
> do we do for a random foo(char*) called with an 'unsigned char*'
> argument? Silence? Hmmm... It's not immediately obvious that it's indeed
> harmless. Yet ano
On Tue, Feb 13, 2007 at 11:29:44PM +0300, Sergei Organov wrote:
> Sorry, what do you do with "variable 'xxx' might be used uninitialized"
> warning when it's false? Turn it off? Annotate the source? Assign fake
> initialization value? Change the compiler so that it does "the effort"
> for you? Neve
On Tuesday 13 February 2007 2:25 pm, Linus Torvalds wrote:
> THE FACT IS, THAT "strlen()" IS DEFINED UNIVERSALLY AS TAKING "char *".
>
> That BY DEFINITION means that "strlen()" cannot care about the sign,
> because the sign IS NOT DEFINED UNIVERSALLY!
>
> And if you cannot accept that fact, it'
"Pekka Enberg" <[EMAIL PROTECTED]> writes:
> On 2/13/07, Sergei Organov <[EMAIL PROTECTED]> wrote:
>> With almost any warning out there one makes more or less efforts to
>> suppress the warning where it gives false positives, isn't it?
>
> Yes, as long it's the _compiler_ that's doing the effort.
>
On Tue, 13 Feb 2007, Sergei Organov wrote:
> > Exactly because "char" *by*definition* is "indeterminate sign" as far as
> > something like "strlen()" is concerned.
>
> Thanks, I now understand that you either don't see the difference
> between "indeterminate" and "implementation-defined" in th
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Tue, 13 Feb 2007, Sergei Organov wrote:
>> >
>> >"I want a char of indeterminate sign"!
>>
>> I'm afraid I don't follow. Do we have a way to say "I want an int of
>> indeterminate sign" in C? The same way there doesn't seem to be a way
>> to say
On 2/13/07, Sergei Organov <[EMAIL PROTECTED]> wrote:
With almost any warning out there one makes more or less efforts to
suppress the warning where it gives false positives, isn't it?
Yes, as long it's the _compiler_ that's doing the effort. You
shouldn't need to annotate the source just to ma
On Tue, 13 Feb 2007, Sergei Organov wrote:
> >
> > "I want a char of indeterminate sign"!
>
> I'm afraid I don't follow. Do we have a way to say "I want an int of
> indeterminate sign" in C? The same way there doesn't seem to be a way
> to say "I want a char of indeterminate sign".
You're w
"Pekka Enberg" <[EMAIL PROTECTED]> writes:
> On 2/13/07, Sergei Organov <[EMAIL PROTECTED]> wrote:
>> May I suggest another definition for a warning being entirely sucks?
>> "The warning is entirely sucks if and only if it never has true
>> positives." In all other cases it's only more or less suc
On 2/13/07, Sergei Organov <[EMAIL PROTECTED]> wrote:
May I suggest another definition for a warning being entirely sucks?
"The warning is entirely sucks if and only if it never has true
positives." In all other cases it's only more or less sucks, IMHO.
You're totally missing the point. False p
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Mon, 12 Feb 2007, Sergei Organov wrote:
>>
>> Why strlen() should be allowed to be called with an incompatible pointer
>> type? My point is that gcc should issue *different warning*, -- the same
>> warning it issues here:
>
> I agree that "strlen()"
Jan Engelhardt <[EMAIL PROTECTED]> wrote:
| Further, giving again answer to the question whether they generate signed or
| unsigned comparisons: Have you ever seen a computer which addresses memory
with
| negative numbers? Since the answer is most likely no, signed comparisons would
| not make sen
On Fri, 9 Feb 2007, Jan Engelhardt wrote:
>
> On Feb 9 2007 15:29, linux-os (Dick Johnson) wrote:
>>>
>>> I was referring to "absolute memory", not the offset magic that assembler
>>> allows. After all, (reg+relativeOffset) will yield an absolute address.
>>> What I was out at: for machines that
On Mon, 12 Feb 2007, Sergei Organov wrote:
>
> Why strlen() should be allowed to be called with an incompatible pointer
> type? My point is that gcc should issue *different warning*, -- the same
> warning it issues here:
I agree that "strlen()" per se isn't different.
The issue is not that the
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Fri, 9 Feb 2007, Sergei Organov wrote:
>>
>> As far as I can read the C99 standard, the "char", "signed char", and
>> "unsigned char", are all different types:
>
> Indeed. Search for "pseudo-unsigned", and you'll see more. There are
> actually cases
Hello!
> void* comparisons are unsigned. Period.
As far as the C standard is concerned, there is no relationship between
comparison on pointers and comparison of their values casted to uintptr_t.
The address space needn't be linear and on some machines it isn't. So
speaking about signedness of po
On Feb 9 2007 15:29, linux-os (Dick Johnson) wrote:
>>
>> I was referring to "absolute memory", not the offset magic that assembler
>> allows. After all, (reg+relativeOffset) will yield an absolute address.
>> What I was out at: for machines that have more than 2 GB of memory, you
>> don't call th
On Fri, 9 Feb 2007, Jan Engelhardt wrote:
>
> On Feb 9 2007 08:16, linux-os (Dick Johnson) wrote:
>> On Fri, 9 Feb 2007, Jan Engelhardt wrote:
>>> On Feb 8 2007 16:42, Linus Torvalds wrote:
>>> Further, giving again answer to the question whether they generate
>>> signed or unsigned comparis
On Thu, 8 Feb 2007 22:27:43 -0500, "D. Hazelton" <[EMAIL PROTECTED]> wrote:
> So almost all the rules around the signs of types are because of a single,
> historical machine. Hence the rules about "char" being unsigned by default
> and "int" being signed by default are because of the nature of t
On Feb 9 2007 08:16, linux-os (Dick Johnson) wrote:
>On Fri, 9 Feb 2007, Jan Engelhardt wrote:
>> On Feb 8 2007 16:42, Linus Torvalds wrote:
>>>
>> Further, giving again answer to the question whether they generate
>> signed or unsigned comparisons: Have you ever seen a computer which
>> addresses
On Fri, 9 Feb 2007, Sergei Organov wrote:
>
> As far as I can read the C99 standard, the "char", "signed char", and
> "unsigned char", are all different types:
Indeed. Search for "pseudo-unsigned", and you'll see more. There are
actually cases where "char" can act differently from _both_ "unsi
On Thu, 8 Feb 2007, David Rientjes wrote:
>
> Yes, I read the 4.1.1 docs:
>
> By default, such a bit-field is signed, because this is
> consistent: the basic integer types such as int are signed
> types.
Ok, so the gcc people have added some language. So what? The fact is, th
Jan Engelhardt <[EMAIL PROTECTED]> writes:
> On Feb 8 2007 08:33, Linus Torvalds wrote:
>>
[...]
> What C needs is a distinction between char and int8_t, rendering "char"
> an unsigned at all times basically and making "unsigned char" and
> "signed char" illegal types in turn.
AFAIK, C already h
On Fri, 9 Feb 2007, Jan Engelhardt wrote:
>
> On Feb 8 2007 16:42, Linus Torvalds wrote:
>>
>> Most C types don't, and some you can't even tell (do pointers generate
>> "signed" or "unsigned" comparisons?
>
> I'd say "neither", because both
>
>signed void *ptr; and
>unsigned void *xyz;
>
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Thu, 8 Feb 2007, Linus Torvalds wrote:
>>
>> But THE CALLER CANNOT AND MUST NOT CARE! Because the sign of "char" is
>> implementation-defined, so if you call "strcmp()", you are already
>> basically saying: I don't care (and I _cannot_ care) what s
On Feb 8 2007 16:42, Linus Torvalds wrote:
>
>Most C types don't, and some you can't even tell (do pointers generate
>"signed" or "unsigned" comparisons?
I'd say "neither", because both
signed void *ptr; and
unsigned void *xyz;
are impossible (and dull at that). That's why you explicit
On Thursday 08 February 2007 19:42, Linus Torvalds wrote:
> Most C types don't, and some you can't even tell (do pointers generate
> "signed" or "unsigned" comparisons? I'll argue that a compiler that
> generates signed comparisons for them is broken, but it tends to be
> something you can only se
On Thu, 8 Feb 2007, Linus Torvalds wrote:
> Even gcc DOES DIFFERENT THINGS! Have you even read the docs?
>
> By default it is treated as signed int but this may be changed by
> the -funsigned-bitfields option.
>
Yes, I read the 4.1.1 docs:
By default, such a bit-field is s
On Thu, 8 Feb 2007, David Rientjes wrote:
>
> Maybe you should read my first post, we're talking about gcc's behavior
> here, not the C standard.
Give it up, David.
Even gcc DOES DIFFERENT THINGS! Have you even read the docs?
By default it is treated as signed int but this may be chan
On Thu, 8 Feb 2007, Linus Torvalds wrote:
> No it's not.
>
> You just don't understand the C language.
>
> And if you don't understand the C language, you can't say "that's what the
> int says". It says no such thing.
>
> The C language clearly says that bitfields have implementation-defined
On Thu, 8 Feb 2007, Linus Torvalds wrote:
>
> The C language clearly says that bitfields have implementation-defined
> types.
Btw, this isn't even some "theoretical discussion". LOTS of compilers do
unsigned bitfields. It may even be the majority. There may (or may not) be
some correlation w
On Thu, 8 Feb 2007, David Rientjes wrote:
>
> Your struct:
>
> struct dummy {
> int flag:1;
> } a_variable;
>
> should expect a_varible.flag to be signed, that's what the int says.
No it's not.
You just don't understand the C language.
And if you don't understan
On Thu, 8 Feb 2007, Linus Torvalds wrote:
> No, making bitfields unsigned is actually usually a good idea. It allows
> you to often generate better code, and it actually tends to be what
> programmers _expect_. A lot of people seem to be surprised to hear that a
> one-bit bitfield actually ofte
On Fri, 9 Feb 2007, J.A. Magallón wrote:
>
> Thats the point. Mmmm, I think I see it the other way around. I defined
> a variable as 'signed' or 'unsigned', because the sign info matters for me.
> And gcc warns about using a function on it that will _ignore_ or even
> misinterpret that info. Co
On Thu, 8 Feb 2007 14:03:06 -0800 (PST), Linus Torvalds <[EMAIL PROTECTED]>
wrote:
>
>
> On Thu, 8 Feb 2007, Linus Torvalds wrote:
> >
> > But THE CALLER CANNOT AND MUST NOT CARE! Because the sign of "char" is
> > implementation-defined, so if you call "strcmp()", you are already
> > basical
On Thu, 8 Feb 2007, David Rientjes wrote:
>
> And a compiler that makes a_variable.flag unsigned would be brain-dead
> because "int" is always signed.
No, making bitfields unsigned is actually usually a good idea. It allows
you to often generate better code, and it actually tends to be what
On Thu, 8 Feb 2007, Linus Torvalds wrote:
> Same goes for
>
> struct dummy {
> int flag:1;
> } a_variable;
>
> which could make "a_variable.d" be either signed or unsigned. In the
> absense of an explicit "signed" or "unsigned" by the programmer, you
> really won't ev
On Thu, Feb 08, 2007 at 02:03:06PM -0800, Linus Torvalds wrote:
>
>
> On Thu, 8 Feb 2007, Linus Torvalds wrote:
> >
> > But THE CALLER CANNOT AND MUST NOT CARE! Because the sign of "char" is
> > implementation-defined, so if you call "strcmp()", you are already
> > basically saying: I don't ca
On Thu, 8 Feb 2007, Linus Torvalds wrote:
>
> But THE CALLER CANNOT AND MUST NOT CARE! Because the sign of "char" is
> implementation-defined, so if you call "strcmp()", you are already
> basically saying: I don't care (and I _cannot_ care) what sign you are
> using.
Let me explain it anothe
On Thu, 8 Feb 2007, J.A. Magallón wrote:
>
> Perhaps the problem is that gcc warns you something like 'if you care
> anything about the sign behaviour of what you send to strlen() you're doomed'.
But you *cannot* care. That's the point. The warning is insane. For any
function that takes "char
On Thu, 8 Feb 2007, Jan Engelhardt wrote:
>
> Thank you for this insight, I don't usually read standards, only RFCs :)
> Uh, does that also apply to the longer types, int, long etc.? I hope not.
No. An "int" or "long" is always signed.
But bitfields, enums or "char" can - and do - have signedn
On Thu, 8 Feb 2007 11:53:38 -0800 (PST), Linus Torvalds <[EMAIL PROTECTED]>
wrote:
>
>
> On Thu, 8 Feb 2007, Jan Engelhardt wrote:
> >
> > I generally have to agree with you about the unsigned char* vs char*. It
> > is a problem of the C language that char can be signed and unsigned, and
> >
On Feb 8 2007 11:53, Linus Torvalds wrote:
>On Thu, 8 Feb 2007, Jan Engelhardt wrote:
>>
>Exactly because "char *" doesn't have a defined sign,
>The user has clearly stated "I don't care about the sign". If a compiler
>complains about us passing "unsigned char *" (or, if "char" is naturally
>un
On Thu, 8 Feb 2007, Jan Engelhardt wrote:
>
> I generally have to agree with you about the unsigned char* vs char*. It
> is a problem of the C language that char can be signed and unsigned, and
> that people, as a result, have used it for storing
> "shorter_than_short_t"s.
>
> What C needs i
On Feb 8 2007 08:33, Linus Torvalds wrote:
>
>And the thing is, sometimes -Wpointer-sign-compare is just horribly
>broken. For example, you cannot write a "strlen()" that doesn't
>complain about "unsigned char *" vs "char *". And that is just a BUG.
>
>I'm continually amazed at how totally cluele
On Thu, 8 Feb 2007, Jeff Garzik wrote:
Just did a pull for the first time since 2.6.20, and a /megaton/ of new
warnings have appeared, on Fedora Core 6/x86-64 "make allyesconfig".
All of the new warnings spew appear to be "pointers differ in signedness"
warning. Granted, we should care about
On Thu, 8 Feb 2007, Jeff Garzik wrote:
>
> Just did a pull for the first time since 2.6.20, and a /megaton/ of new
> warnings have appeared, on Fedora Core 6/x86-64 "make allyesconfig".
That was due to the Makefile rule breakage. Hopefully it now _really_ is
fixed. The
CFLAGS += $(call
Just did a pull for the first time since 2.6.20, and a /megaton/ of new
warnings have appeared, on Fedora Core 6/x86-64 "make allyesconfig".
All of the new warnings spew appear to be "pointers differ in
signedness" warning. Granted, we should care about these, but even a
"silent" build (make
68 matches
Mail list logo
