From owner-freebsd-arch@FreeBSD.ORG Sun Nov 16 02:20:13 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C734F16A4CE for ; Sun, 16 Nov 2003 02:20:13 -0800 (PST) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F75D43F93 for ; Sun, 16 Nov 2003 02:20:11 -0800 (PST) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (verified OK)) by gw.celabo.org (Postfix) with ESMTP id 030C35489C; Sun, 16 Nov 2003 04:20:11 -0600 (CST) Received: by madman.celabo.org (Postfix, from userid 1001) id 851C36D455; Sun, 16 Nov 2003 04:20:10 -0600 (CST) Date: Sun, 16 Nov 2003 04:20:10 -0600 From: "Jacques A. Vidrine" To: Terry Lambert Message-ID: <20031116102010.GA53282@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Terry Lambert , freebsd-arch@freebsd.org References: <20031114194119.GA94198@madman.celabo.org> <3FB6AA8F.37ED6D50@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FB6AA8F.37ED6D50@mindspring.com> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.4i-ja.1 cc: freebsd-arch@freebsd.org Subject: Re: __TIME_MIN/__TIME_MAX X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Nov 2003 10:20:13 -0000 On Sat, Nov 15, 2003 at 02:37:03PM -0800, Terry Lambert wrote: > "Jacques A. Vidrine" wrote: > > In at least one place in libc, it is necessary to range check a time_t > > value. One most platforms, time_t has the same range as `int', but > > on at least amd64, it has a larger range. Any objections to adding > > definitions of __TIME_MIN and __TIME_MAX to sys/${arch}/_limits.h? > > > > I could just do the usual check for lossage after casting, except that > > in theory time_t could be a floating-point value (but not in reality > > in FreeBSD). It seems cleaner to me to have an explicit range. > > XSI: time_t and clock_t shall be integer or real-floating types. > > The range should be derived from th type. Defining separate values > outside the implementation namespace might be OK, but keeping those > values synchronized with the size_t is likely to be painful for > years to come. I don't think I understand your point. time_t and size_t have no relationship. The __TIME_MIN/__TIME_MAX I was suggesting would have been analogous to other numerical limits defined in such as INT_MIN/INT_MAX or our implementation-only __OFF_MIN/__OFF_MAX. Yes, they'd need to be synchronized with the actual type in use, e.g. #define __TIME_MAX __INT_MAX /* most platforms */ #define __TIME_MAX __LONG_MAX /* ia64, amd64 */ (Note that now, I don't intend to implement this because it doesn't actually help me get out of the quandry I was in. But, I still feel like discussing if anyone is interested :-) By the way, that quote from SUSv3 (``shall be integer or real-floating types'') is what messes me up. time_t could be signed or unsigned. If it were unsigned (extremely unlikely, but OK according to the letter of the standard), then I don't think I can detect certain range errors. /* How can this be implemented correctly? */ int range_error(long n, time_t t) { return (long)(t = n) == n; } Too bad (IMHO) C never grew other operators like sizeof that let you examine type attributes. Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal nectar@celabo.org jvidrine@verio.net nectar@freebsd.org nectar@kth.se