AW: ecpg long int problem on alpha + fix - Mailing list pgsql-hackers

From Zeugswetter Andreas SB
Subject AW: ecpg long int problem on alpha + fix
Date
Msg-id 11C1E6749A55D411A9670001FA68796336826F@sdexcsrv1.f000.d0188.sd.spardat.at
Whole thread Raw
Responses Re: ecpg long int problem on alpha + fix  (Michael Meskes <meskes@postgresql.org>)
List pgsql-hackers
> > Could you please try to just remove the cpp flag? Also I wonder why you are
> > using "long long int" instead of just "long int" in your C program. Well
> > that is the people who complained to you.
> 
> Yes, dropping the CPP flags solves the problem for us. I assume all
> platforms have long long now?
> 
> We used long long as this seems to be pretty consistently 64 bits on
> different platforms, and our code runs on Tru64, PC linux and openBSD.

I think the people did the perfectly correct thing to use long long int,
since that makes their code more portable.
Can someone try to help me understand this please ?
My understanding so far is:1. long int is the same as long (32 or more bits)2. long long int is at least 64 bits (I
haveso far not seen more that 64 bits)    (my original understanding was that it is 64bits, but Tom corrected me)
 

So my conclusion would be, that ecpg should understand "long long int" since
that is preferable over a "long int" that is 64bits by chance.

I do agree with the statement, that HAVE_LONG_LONG_INT_64 shoud be
defined on all platforms where the compiler understands it to be 64bits.
It would imho be the responsibility of backend code, to only do one of
the two if both are defined.
Otherwise the defines should have a different name like USE_....

Andreas


pgsql-hackers by date:

Previous
From: Tom Ivar Helbekkmo
Date:
Subject: Re: [lockhart@alumni.caltech.edu: Third call for platform testing]
Next
From: Michael Meskes
Date:
Subject: Re: ecpg long int problem on alpha + fix