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: Chung-Ju Wu <jasonwucj at gmail dot com>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: Andrew Chi <achi at bbn dot com>, "gcc-help at gcc dot gnu dot org" <gcc-help at gcc dot gnu dot org>
- Date: Wed, 20 Mar 2013 12:30:14 +0800
- Subject: Re: parsing precedence of long integer literal "L"
- References: <5148C45E dot 5060506 at bbn dot com> <CAKOQZ8wsA0WdsmfH39CJEqRAqSu73r4Dz6ECVJkuf2QMCtuHzQ at mail dot gmail dot com>
2013/3/20 Ian Lance Taylor <iant@google.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
Hi, Andrew,
What Ian said in the mail can be refered to: C99 6.4.4.1 Point 5.
Best regards,
jasonwucj