Re: [HACKERS] Also on SVR4 (Compiling 6.4 on NetBSD-current/pc532)

>  > > ... 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