This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: parsing precedence of long integer literal "L"
- From: Ian Lance Taylor <iant at google dot com>
- To: Andrew Chi <achi at bbn dot com>
- Cc: "gcc-help at gcc dot gnu dot org" <gcc-help at gcc dot gnu dot org>
- Date: Tue, 19 Mar 2013 21:25:51 -0700
- Subject: Re: parsing precedence of long integer literal "L"
- References: <5148C45E dot 5060506 at bbn dot com>
On Tue, Mar 19, 2013 at 1:02 PM, Andrew Chi <achi@bbn.com> wrote:
> I'm confused about the parsing of the "L" which should denote a long integer
> literal. I'm running GCC 4.5.3 on a 32-bit machine, i.e. long long = 64
> bits and long = 32 bits. Am I misunderstanding the precedence of "L" or how
> it's parsed/converted?
You didn't really say what your confusion was. I guess that you are
wondering why these two lines give you different values.
> long long y = (0xffffffffL);
> long long z = (long)(0xffffffffL);
It's because when the C compiler sees an integer constant, the type
depends on the value. For a hex constant with an 'L' suffix, the type
given is the first of the following types in which the value can be
represented: long, unsigned long, long long, unsigned long long. In
the case of 0xffffffffL on a 32-bit machine, the first of those types
in which the value can be represented is unsigned long. When an
unsigned long value is assigned to a long long variable, it is
zero-extended. When an unsigned long value is cast to a long value,
the result is, of course, a long, which is signed. When a long is
assigned to a long long variable, it is sign-extended.
Ian