Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1423200AbXBIAm5 (ORCPT ); Thu, 8 Feb 2007 19:42:57 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1423185AbXBIAm4 (ORCPT ); Thu, 8 Feb 2007 19:42:56 -0500 Received: from smtp.osdl.org ([65.172.181.24]:47352 "EHLO smtp.osdl.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1423156AbXBIAmz (ORCPT ); Thu, 8 Feb 2007 19:42:55 -0500 Date: Thu, 8 Feb 2007 16:42:40 -0800 (PST) From: Linus Torvalds To: David Rientjes cc: Jan Engelhardt , Jeff Garzik , Linux Kernel Mailing List , Andrew Morton Subject: Re: somebody dropped a (warning) bomb In-Reply-To: Message-ID: References: <45CB3B28.60102@garzik.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1847 Lines: 59 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 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. So when you see struct dummy { int flag:1; } a_variable; if you don't read that as "oh, the sign of 'flag' is implementation- defined", then you simply aren't reading it right. Is it "intuitive"? Nobody ever really called C an _intuitive_ language. C has a lot of rules that you simply have to know. The bitfield sign rule is just one such rule. > There is no special case here with regard to type. Sure there is. Read the spec. I don't understand why you are arguing. YOU ARE WRONG. Bitfields simply have implementation-defined signedness. As do enums. As does "char". It really is that simple. The *real* special case is actually "int" and "long". In many ways, the fact that those *do* have a well-specified signedness is actually the exception rather than the rule. 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 with a standards- conforming proghram if you can allocate memory across the sign boundary, which may or may not be true..) Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/