From: | Adriaan Joubert <a(dot)joubert(at)albourne(dot)com> |
---|---|
To: | |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql(at)rkirkpat(dot)net, pgsql-ports(at)postgreSQL(dot)org, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Re: [HACKERS] Re: Call for port testing on fmgr changes -- Results! |
Date: | 2000-06-25 07:17:52 |
Message-ID: | 3955B220.72F7104D@albourne.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-ports |
Thomas Lockhart wrote:
> > Hmm, that makes all kinds of sense if time_t is not the same size as
> > AbsoluteTime --- which wouldn't surprise me at all on a 64-bit system.
> > time_t *ought* to be 64-bits on such a machine. The casts in that
> > routine,
> > tx = localtime((time_t *) &time);
> > are obviously bogus if so. Can anyone with an Alpha comment?
>
> I haven't had an Alpha for a couple of years, but I *strongly* recall
> that time_t is 64 bits on that machine.
>
In <sys/types.h> time_t is defined as an int4, i.e. 4 bytes. To
double-check I wrote a program to print sizeof:
sizeof(time_t)=4 (DU 4.0F, cc)
So I guess it is 32 bits. On the whole they have stuck to traditional sizes
for traditional types -- it would just have broken too many programmes
otherwise. Of course they are going to have to make time_t 64 bits within
the next 30 years ....
Adriaan
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2000-06-25 12:21:27 | Re: SQL_TEXT (Re: Re: Big 7.1 open items) |
Previous Message | Thomas Lockhart | 2000-06-25 04:55:08 | Re: SQL_TEXT (Re: Re: Big 7.1 open items) |
From | Date | Subject | |
---|---|---|---|
Next Message | Ryan Kirkpatrick | 2000-06-25 15:31:53 | Re: [HACKERS] Re: Call for port testing on fmgr changes -- Results! |
Previous Message | Thomas Lockhart | 2000-06-25 04:36:13 | Re: [HACKERS] Re: Call for port testing on fmgr changes -- Results! |