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
