Re: [HACKERS] Found it. Also on SVR4 (Compiling 6.4 on NetBSD...

Thanks to your suggestion, the '0' is indeed the problem. Apparently a
compiler problem, since the function prototypes are not correctly
coerced. Prefixing the 0 with (double) did it.

 > Here is the call in the code:
 >
 >         tm2datetime(&tt, 0, NULL, &dt);
 >

Thanx again.

Thomas G. Lockhart writes:
 > >  > > ... I suspect (a NetBSD/pc532 problem) due to a lack of people
 > >  > > screaming.
 > >  > Screaming means you get to help do development :)
 > > Well, finally somebody, who sees the same problems as me. I had the
 > > same problems with 6.3, which I didn't pursue due to lack off time.
 >
 > Frank, do I hear you screaming? :)
 >
 > > However, now I retried with the 6.4 snapshot from Sep. 11. I compiled
 > > under Siemens SINIX (Mips based SVR4) and the system cc.
 > > If I issue the following sql statement, the backend dies with a core.
 > >   regression=> select ('now'::datetime - 'current'::datetime);
 > > I guess the following result is ok.
 > >   regression=> select ('current'::datetime) as "Zero";
 >
 > Yes.
 >
 > > I guess, somehow the applying math operators to datetime causes the
 > > core dumps.
 >
 > No. (or, not likely...)
 >
 > > Here is the GDB stack trace from the core. (Only dt.c ...
 > > (gdb) where
 > > #0  0x51595c in tm2datetime (tm=0x7fffb334, fsec=1.0609881999384027e-314,
 > >     tzp=0x5db6d4, result=0x542658) at dt.c:2517
 >
 > Here is the call in the code:
 >
 >         tm2datetime(&tt, 0, NULL, &dt);
 >
 > Note that fsec is not the zero-value it should be, and that tzp is not
 > null (zero usually) as it should be. So, somehow your system is not
 > converting the second argument zero in the call to
 >   (double) 0.0e0
 > and that is also screwing up the alignment for the next argument.
 >
 > Here is the declaration for tm2datetime() (in include/utils/dt.h):
 >
 > extern int  tm2datetime(struct tm * tm, double fsec,
 >                         int *tzp, DateTime *dt);
 >
 > which is pretty clear on what the arguments should be. So, you can
 > probably change/coerce the call inside SetDateTime() to make sure that
 > the second argument is a double zero:
 >
 >         tm2datetime(&tt, 0.0e0, NULL, &dt);
 >
 > but I'm not sure why your system would be ignoring the declaration for
 > the routine. Are there some switches you can set on your compiler so it
 > does the right thing? Something like
 >
 >   --stop-annoying-frank
 > or
 >   --actually-use-standard-C-conventions
 >
 > ?? ;-)
 >
 > > Oh, one more thing. With 6.3, when psql lost connection with the
 > > backend, I got an error message saying so. With 6.4 it psql seems to
 > > be simply hanging.
 >
 > One thing at a time. Although I find that mine core dumps about as well
 > as ever...
 >
 >                         - Tom