Re: ecpg long int problem on alpha + fix

On Wed, Apr 04, 2001 at 05:47:50PM +0300, Adriaan Joubert wrote:
> This has nothing to do with the backend. ecpg itself core-dumps after
> calling abort() at the end of the switch statement in typename.c, when
> processing a .pgc file. As people complained to me about ecpg

Yes, I did understand that. What I do not understand is the problem with
long long int. On an alpha the normal long int should be sufficient for
storing int8.

> core-dumping I tried to find out why and then found that it called the
> abort() at the end of this switch ;-)

This abort() is used to make sure ecpg stops if a type id is found that does
not exist. Normally this must not happen. Ah, now I understand, the parser
accepts long long but typename.c does not like that.

It should be sufficient to just remove the #ifdef in typename.c since
nothing serious is happening there. The reason for this precompiler define
is to make sure that no long long code is generated that the C compiler
cannot cope with. But in typename.c there is no code generated other than
the creation of a string.

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.

> an int8 column in a table, we need to use a 64 bit type, i.e. a 'long
> long', and as HAVE_LONG_LONG_INT_64 is not true, no such type is

I thought "long int" is 64 bits too, so that should be sufficient.

> From Tom's mail I gather that it is not an option to define
> HAVE_LONG_LONG_INT_64 on alpha, so I think this patch, or something
> similar, is necessary.

Thanks to Tom btw for setting this straight.

> Apologies for not being clear enough initially.

I think you were pretty clear from teh get go, but I simply misunderstood
you.

Michael
-- 
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!