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
> >
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
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
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
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
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
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
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
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
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
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 +=
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
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 -s)
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
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 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 clueless some gcc
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_ts.
What C needs is a
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
unsigned on that
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
that
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 signedness that
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, 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 another way.
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 care (and I
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 even _know_
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 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
basically saying: I
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. Could
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 often
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 understand the C
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 with
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
types.
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
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
On Thursday 08 February 2007 19:42, Linus Torvalds wrote:
snip
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 see
101 - 136 of 136 matches
Mail list logo
