Re: Distinguishing between long and long long on an LP64 machine?

[Mark Dickinson <dickinsm at gmail dot com>]

On Tue, Oct 27, 2009 at 12:32 PM, John (Eljay) Love-Jensen
<eljay@adobe.com> wrote:
> Hi Mark,
>
>> If I'm using gcc on a machine where both long and long long also have 64 bits,
>> is there any simple C99 (+ gcc extension) code that will allow me to figure
>> out whether this type is ultimately defined as long or long long?
>
> If you are using C++, yes. ÂIf you are using C... I don't think so.

Many thanks for the response, and sorry for the delay in replying.

> For your example, this is how I do it:
>
> off_t my_offset;
> //...
> printf("%lld", (long long)my_offset);

Thanks.  That's more-or-less what I've ended up with, modulo
worrying about Windows/MSVC, and about platforms that
don't have long long.  I just wanted to make sure I wasn't
missing some other obvious solution for silencing these gcc
warnings.

To provide a bit of context, I was working on a portion of the
Python codebase, which mostly tries to be C89 conforming.
C99 features like long long or int64_t are used, but they're
usually enclosed in appropriate preprocessor conditionals,
with some C89 fallback code that's supposed to work
everywhere.  (And catering to MSVC adds another layer of
complexity.)

The code in question (see the _buffered_raw_tell function in
[1] if you want the gory details) was printing expressions of
type off_t using "%zd", leading (naturally) to gcc warnings
on Unix.  To a younger and more foolish me it looked like
a five minute task to fix this.  Now I'm older and wiser!

>> ... I'm still curious to know whether there's a simple way for a gcc *user* to
>> distinguish between long and long long when both are 64 bits. Âtypeof doesn't
>> seem to help here. ÂI guess I'm really after some imaginary extension
>> 'rank_of' that lets me do
>
> C? ÂI don't think so.

Okay, thanks. As far as I can tell from staring at the standards,
in the absence of permitted oddities like paddings bit or trap
representations, it seems that two two's complement signed
integer types of different ranks but the same precision are
completely indistinguishable (with respect to semantics) within
standard C.  With gcc, the warning I get from printf seems to
be the only visible difference.

Mark

[1] http://svn.python.org/view/python/trunk/Modules/_io/bufferedio.c?view=markup