Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 28 Oct 2001 09:22:42 -0700
From:      Brad Huntting <huntting@hunkular.glarp.com>
To:        Matthew Dillon <dillon@apollo.backplane.com>
Cc:        arch@FreeBSD.ORG
Subject:   Re: need review make time_t type agnostic changes 
Message-ID:  <200110281622.f9SGMgZ71251@hunkular.glarp.com>
In-Reply-To: Your message of "Sat, 27 Oct 2001 17:55:35 PDT." <200110280055.f9S0tZ184290@apollo.backplane.com> 

next in thread | previous in thread | raw e-mail | index | archive | help

>   Here is a diff for review to remove int truncation of time in make.
>   There is still an issue in that the archive format can only handle 11
>   useful digits, so its only good for 10^11 seconds, but that's
>   the way it goes.  I didn't even know make *tried* to read the
>   table of contents for an archive!  Must be some weird mis-feature.

>   In anycase, make needed to be fixed anyway since half the routines
>   cast time_t to an int, which breaks any conceivable notion of the
>   proper handling of time_t.

I know this is obvious, but while your at it, could you define a
preprocessor flag such as -D__USE_OLD_TIME_T=1 for non-kernel apps?

I doubt it's worth the trouble to have two such flags __USE_INT_TIME_T
versus __USE_LONG_TIME_T, so I would vote for only one backward
compatibility flag which exactly reproduces the old behavior (int).

If the consensus is that this should _not_ debut in 5.0, then we
could do something like

	#if	!defined(__USE_OLD_TIME_T) && !defined(__USE_NEW_TIME_T)
	#define	__USE_OLD_TIME_T
	#endif

	#ifdef	__USE_OLD_TIME_T
	typedef	time_t	int;
	#else
	typedef	time_t	int64_t;
	#endif

which would allow people to easily test the new 64bit time_t.


brad

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200110281622.f9SGMgZ71251>