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
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
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
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's C
problem that it
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 to
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 it's
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 somebody is
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
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
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
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 defaulting to
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 either don't see the
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 came out in
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 signedness of char,
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.
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
>
> 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's
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
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
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
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
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
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
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 does the
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 longer
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 latter
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
*worse* from a
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 true
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 immediately
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 indeterminate and
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's wrong.
If theory is very
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
*other*
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.
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
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 more or
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
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
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?
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,
"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
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
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
"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
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
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
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
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() per se isn't
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
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 sucks, IMHO.
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 wrong.
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
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 I want a char of
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 this context or
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.
You
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's your
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? Never
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
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 false
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
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
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 where char can act
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
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 have more than
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
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
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
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
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
>>
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_
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,
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
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
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
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 explicitly will
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 sign you are
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;
are impossible
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 has 3
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, that
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_ unsigned
char
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 memory
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 the PDP-11.
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 comparisons: Have you
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 the address
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
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
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 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:
> 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
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
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
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.
1 - 100 of 136 matches
Mail list logo
