From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S265241AbUGGQdm (ORCPT ); Wed, 7 Jul 2004 12:33:42 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S265205AbUGGQdm (ORCPT ); Wed, 7 Jul 2004 12:33:42 -0400 Received: from ltgp.iram.es ([150.214.224.138]:13185 "EHLO ltgp.iram.es") by vger.kernel.org with ESMTP id S265248AbUGGQcY (ORCPT ); Wed, 7 Jul 2004 12:32:24 -0400 From: Gabriel Paubert Date: Wed, 7 Jul 2004 18:30:49 +0200 To: tom st denis Cc: linux-kernel@vger.kernel.org Subject: Re: 0xdeadbeef vs 0xdeadbeefL Message-ID: <20040707163048.GA30840@iram.es> References: <20040707030029.GD12308@parcelfarce.linux.theplanet.co.uk> <20040707111028.82649.qmail@web41111.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040707111028.82649.qmail@web41111.mail.yahoo.com> User-Agent: Mutt/1.5.6+20040523i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 07, 2004 at 04:10:28AM -0700, tom st denis wrote: > --- viro@parcelfarce.linux.theplanet.co.uk wrote: > > On Tue, Jul 06, 2004 at 05:06:12PM -0700, tom st denis wrote: > > > --- David Eger wrote: > > > > Is there a reason to add the 'L' to such a 32-bit constant like > > this? > > > > There doesn't seem a great rhyme to it in the headers... > > > > > > IIRC it should have the L [probably UL instead] since numerical > > > constants are of type ``int'' by default. > > > > > > Normally this isn't a problem since int == long on most platforms > > that > > > run Linux. However, by the standard 0xdeadbeef is not a valid > > unsigned > > > long constant. > > > > ... and that would be your F for C101. Suggested remedial reading > > before > > you take the test again: any textbook on C, section describing > > integer > > constants; alternatively, you can look it up in any revision of C > > standard. > > Pay attention to difference in the set of acceptable types for > > decimal > > and heaxdecimal constants. > > You're f'ing kidding me right? Dude, I write portable ISO C source > code for a living. My code has been built on dozens and dozens of > platforms **WITHOUT** changes. I know what I'm talking about. > > 0x01, 1 are 01 all **int** constants. > > On some platforms 0xdeadbeef may be a valid int, in most cases the > compiler won't diagnostic it. splint thought it was worth mentioning > which is why I replied. > > In fact GCC has odd behaviour. It will diagnostic > > char x = 0xFF; > > and > > int x = 0xFFFFFFFFULL; > > But not > > int x = 0xFFFFFFFF; > > [with --std=c99 -pedantic -O2 -Wall -W] > > So I'd say it thinks that all of the constants are "int". In this case > 0xFF is greater than 127 [max for char] and 0xFFFFFFFFFFULL is larger You are aware that this statement is plainly and simply wrong, aren't you? On many platforms a "plain" char is unsigned. You can't write portable code without knowing this. > > Before you step down to belittle others I'd suggest you actually make > sure you're right. Ditto. Gabriel