This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: parsing precedence of long integer literal "L"


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]