Date: Wed, 22 Dec 2004 15:14:50 +0100 From: Erik Trulsson <ertr1013@student.uu.se> To: Pete French <petefrench@ticketswitch.com> Cc: colin.percival@wadham.ox.ac.uk Subject: Re: Will there be a 5.3.1? Message-ID: <20041222141450.GA51987@falcon.midgard.homeip.net> In-Reply-To: <E1Ch5Z5-000FuI-TV@dilbert.firstcallgroup.co.uk> References: <20041221192924.GA27658@falcon.midgard.homeip.net> <E1Ch5Z5-000FuI-TV@dilbert.firstcallgroup.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Dec 22, 2004 at 12:26:03PM +0000, Pete French wrote: > > Buggy compilers are indefensible, yes, but why try to apologise for it? > > I dont see it as a bug. Without an 'L' the right hand side of that > expression is a 16 bit int. For which 65536 is out of range. If I > wrote 'int y = 65535; long x = y;' then I would get the same result for > the same reason. Wrong. With 16-bit int the constant 65536 has type long. The type of a decimal integer constant without any suffix is the first of 'int', 'long', 'long long' in which the constant can be represented. (For C89 it was the first of 'int', 'long', 'unsigned long') (See 6.4.4.1 in the C99 standard.) Your example of 'int y = 65535; long x = y;' on the other hand causes implementation-defined behaviour for 16-bit ints. (As do all other instances of overflow for signed integer types.) > > The correct line is 'long x = 65535L;' which specifies that the constant > is a long. In fact aren't situations like this the precise reason for > having the 'L' as part of the language ? > > > 'long x = 65535;' will not set x to -1, even with 16-bit ints. > > It will and does on certain compilers unfortunately. No doubt, but if it does the compilers are buggy. -- <Insert your favourite quote here.> Erik Trulsson ertr1013@student.uu.se
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041222141450.GA51987>