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"


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


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