Michael Meskes wrote:
>
> On Tue, Apr 03, 2001 at 06:32:25PM +0300, Adriaan Joubert wrote:
> > we had a problem on Alpha that in interfaces/ecpg/lib/typename.c we
> > have
> > HAVE_LONG_INT_64 defined, but not HAVE_LONG_LONG_INT_64. Consequently no
>
> Sure since that means your long int a
Michael Meskes <[EMAIL PROTECTED]> writes:
> I just committed some changes so that ecpg does acceptt "long long"
> variables all the time, but repleces them with type "long" if
> HAVE_LONG_LONG_INT_64 is not defined.
This looks like a workable strategy for now. Ten years from now, when
"long" me
On Thu, Apr 05, 2001 at 10:01:53AM +0200, Zeugswetter Andreas SB wrote:
> 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
On Thu, Apr 05, 2001 at 09:13:49AM +0300, Adriaan Joubert wrote:
> I think we probably do need the CPP defines from my patch in there, so
Not exactly. The test in typename.c does not make sense at all. It will be
removed. But there are other places where it is needed. Or can I safely
assume that
> > 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
Tom Lane wrote:
>
> Adriaan Joubert <[EMAIL PROTECTED]> writes:
> > Yes, dropping the CPP flags solves the problem for us. I assume all
> > platforms have long long now?
>
> Surely you jest.
Yep, it was a rhetorical question.
I think we probably do need the CPP defines from my patch in there,
Adriaan Joubert <[EMAIL PROTECTED]> writes:
> Yes, dropping the CPP flags solves the problem for us. I assume all
> platforms have long long now?
Surely you jest.
regards, tom lane
---(end of broadcast)---
TIP 5: Have you c
> 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?
W
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 t
Michael Meskes wrote:
>
> On Wed, Apr 04, 2001 at 03:35:34PM +0300, Adriaan Joubert wrote:
> > OK, I see. Problem is that without the fix ecpg aborts when writing to a
> > table with an int8 column using valid code.
>
> Sorry, I still don't seem to understand that. Data between ecpg and the
> ba
Michael Meskes <[EMAIL PROTECTED]> writes:
>> all exist on alpha and are all 64 bits, but HAVE_LONG_LONG_INT_64 is not
>> defined, so ecpg cannot handle ECPGt_long_long types. It is not clear to
> I see. I was under the impression that HAVE_LONG_LONG_INT_64 should be
> defined if long long int is
On Wed, Apr 04, 2001 at 03:35:34PM +0300, Adriaan Joubert wrote:
> OK, I see. Problem is that without the fix ecpg aborts when writing to a
> table with an int8 column using valid code.
Sorry, I still don't seem to understand that. Data between ecpg and the
backend is tranfered in ascii only. Wha
On Tue, Apr 03, 2001 at 06:32:25PM +0300, Adriaan Joubert wrote:
> we had a problem on Alpha that in interfaces/ecpg/lib/typename.c we
> have
> HAVE_LONG_INT_64 defined, but not HAVE_LONG_LONG_INT_64. Consequently no
Sure since that means your long int and not your long long int is 64 bits.
Hi,
we had a problem on Alpha that in interfaces/ecpg/lib/typename.c we
have
HAVE_LONG_INT_64 defined, but not HAVE_LONG_LONG_INT_64. Consequently no
code is included for long ints and typename calls *abort*. I put in a
few lines that check for HAVE_LONG_INT_64 and seem to generate the ri
14 matches
Mail list logo
