From: Linus Torvalds <torvalds@linux-foundation.org>
To: Jan Engelhardt <jengelh@linux01.gwdg.de>
Cc: Jeff Garzik <jeff@garzik.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: somebody dropped a (warning) bomb
Date: Thu, 8 Feb 2007 13:37:50 -0800 (PST) [thread overview]
Message-ID: <Pine.LNX.4.64.0702081324090.8424@woody.linux-foundation.org> (raw)
In-Reply-To: <Pine.LNX.4.61.0702082202180.24888@yvahk01.tjqt.qr>
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 depends
on the architecture and/or compiler writers whims.
So if you do
enum my_enum {
orange = 1,
blue = 2,
green = 3
};
you don't know if "enum my_enum" is signed or not. The compiler could
decide to use "int". Or it could decide to use "unsigned char" for it. You
simply don't know.
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_ whether "flag" can contain the values {0,1} or
{-1,0}.
Normally you wouldn't ever even care. A one-bit bitfield would only ever
really be tested against 0, but it really is possible that when you assign
"1" to that value, and read it back, it will read back -1. Try it.
Those are the three only types I can think of, but the point is, they
really don't have any standard-defined sign. It's up to the compiler.
Now, passing a "pointer to bitfield" is impossible, and if you pass a
pointer to an enum you'd better *always* use the same enum anyway (because
not only is the signedness implementation-defined, the _size_ of the enum
is also implementation-defined), so in those two cases, -Wpointer-sign
doesn't hurt.
But in the case of "char", it really is insane. It's doubly insane exactly
because the C standard defines a lot of standard functions that take "char
*", and that make tons of sense with unsigned chars too, and you may have
100% good reasons to use "unsigned char" for many of them.
> >It really is that simple. gcc is broken. The C language isn't, it's purely
> >a broken compiler issue.
>
> Maybe you could send in a patch to gcc that fixes the issue?
I've butted heads with too many broken gcc decisions. I've occasionally
used to try to discuss these kinds of things on the gcc mailing lists, but
I got too fed up with language lawyers that said "the standard _allows_ us
to be total *ssholes, so stop complaining". It seemed to be an almost
universal defense.
(And yes, the standard allows any warnings at all. So technically, gcc can
warn about whatever hell it wants. It doesn't make it a good idea).
Linus
next prev parent reply other threads:[~2007-02-08 21:38 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-08 15:00 somebody dropped a (warning) bomb Jeff Garzik
2007-02-08 16:33 ` Linus Torvalds
2007-02-08 18:42 ` Jan Engelhardt
2007-02-08 19:53 ` Linus Torvalds
2007-02-08 21:10 ` Jan Engelhardt
2007-02-08 21:37 ` Linus Torvalds [this message]
2007-02-08 23:12 ` David Rientjes
2007-02-08 23:37 ` Linus Torvalds
2007-02-09 0:24 ` David Rientjes
2007-02-09 0:42 ` Linus Torvalds
2007-02-09 0:59 ` Linus Torvalds
2007-02-09 0:59 ` David Rientjes
2007-02-09 1:11 ` Linus Torvalds
2007-02-09 1:18 ` David Rientjes
2007-02-09 15:38 ` Linus Torvalds
2007-02-09 3:27 ` D. Hazelton
2007-02-09 19:54 ` Pete Zaitcev
2007-02-09 12:34 ` Jan Engelhardt
2007-02-09 13:16 ` linux-os (Dick Johnson)
2007-02-09 17:45 ` Jan Engelhardt
2007-02-09 20:29 ` linux-os (Dick Johnson)
2007-02-09 22:05 ` Jan Engelhardt
2007-02-09 22:58 ` Martin Mares
2007-02-12 18:50 ` linux-os (Dick Johnson)
2007-02-13 15:14 ` Dick Streefland
2007-02-08 21:13 ` J.A. Magallón
2007-02-08 21:42 ` Linus Torvalds
2007-02-08 22:03 ` Linus Torvalds
2007-02-08 22:19 ` Willy Tarreau
2007-02-09 0:03 ` J.A. Magallón
2007-02-09 0:22 ` Linus Torvalds
2007-02-09 12:38 ` Sergei Organov
2007-02-09 15:58 ` Linus Torvalds
2007-02-12 11:12 ` Sergei Organov
2007-02-12 16:26 ` Linus Torvalds
2007-02-13 18:06 ` Sergei Organov
2007-02-13 18:26 ` Pekka Enberg
2007-02-13 19:14 ` Sergei Organov
2007-02-13 19:43 ` Pekka Enberg
2007-02-13 20:29 ` Sergei Organov
2007-02-13 21:31 ` Jeff Garzik
2007-02-13 23:21 ` Linus Torvalds
2007-02-15 13:20 ` Sergei Organov
2007-02-15 15:57 ` Linus Torvalds
2007-02-15 18:53 ` Sergei Organov
2007-02-15 19:02 ` Linus Torvalds
2007-02-15 20:23 ` me, not " Oleg Verych
2007-02-16 4:26 ` Rene Herman
2007-02-19 11:58 ` Sergei Organov
2007-02-19 13:58 ` Sergei Organov
2007-02-15 22:32 ` Lennart Sorensen
2007-02-13 19:25 ` Linus Torvalds
2007-02-13 19:59 ` Sergei Organov
2007-02-13 20:24 ` Linus Torvalds
2007-02-15 15:15 ` Sergei Organov
2007-02-13 21:13 ` Rob Landley
2007-02-13 22:21 ` Olivier Galibert
2007-02-14 12:52 ` Sergei Organov
2007-02-15 20:06 ` Sergei Organov
2007-02-09 15:10 ` Sergei Organov
2007-02-08 16:35 ` Kumar Gala
[not found] <7Mj5f-3oz-21@gated-at.bofh.it>
[not found] ` <7MktH-5EW-35@gated-at.bofh.it>
[not found] ` <7Mmvy-vj-17@gated-at.bofh.it>
[not found] ` <7MnBC-2fk-13@gated-at.bofh.it>
[not found] ` <7MoQx-4p8-11@gated-at.bofh.it>
[not found] ` <7MpjE-50z-7@gated-at.bofh.it>
[not found] ` <7MpCS-5Fe-9@gated-at.bofh.it>
[not found] ` <7MDd7-17w-1@gated-at.bofh.it>
[not found] ` <7MGkB-62k-31@gated-at.bofh.it>
[not found] ` <7NHoe-2Mb-37@gated-at.bofh.it>
[not found] ` <7NMe9-1ZN-7@gated-at.bofh.it>
[not found] ` <7Oagl-6bO-1@gated-at.bofh.it>
[not found] ` <7ObvW-89N-23@gated-at.bofh.it>
[not found] ` <7Oc8t-NS-1@gated-at.bofh.it>
2007-02-15 20:08 ` Bodo Eggert
2007-02-16 11:21 ` Sergei Organov
2007-02-16 14:51 ` Bodo Eggert
2007-02-19 11:56 ` Sergei Organov
2007-02-16 12:46 ` Sergei Organov
2007-02-16 17:40 ` Bodo Eggert
2007-02-19 12:17 ` Sergei Organov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.0702081324090.8424@woody.linux-foundation.org \
--to=torvalds@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=jeff@garzik.org \
--cc=jengelh@linux01.gwdg.de \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).