AW: ecpg long int problem on alpha + fix

Поиск
Список
Период
Сортировка
От Zeugswetter Andreas SB
Тема AW: ecpg long int problem on alpha + fix
Дата
Msg-id 11C1E6749A55D411A9670001FA68796336826F@sdexcsrv1.f000.d0188.sd.spardat.at
обсуждение исходный текст
Ответы Re: ecpg long int problem on alpha + fix  (Michael Meskes <meskes@postgresql.org>)
Список 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 по дате отправления:

Предыдущее
От: Tom Ivar Helbekkmo
Дата:
Сообщение: Re: [lockhart@alumni.caltech.edu: Third call for platform testing]
Следующее
От: Michael Meskes
Дата:
Сообщение: Re: ecpg long int problem on alpha + fix