Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 16 Nov 2003 04:20:10 -0600
From:      "Jacques A. Vidrine" <nectar@FreeBSD.org>
To:        Terry Lambert <tlambert2@mindspring.com>
Cc:        freebsd-arch@freebsd.org
Subject:   Re: __TIME_MIN/__TIME_MAX
Message-ID:  <20031116102010.GA53282@madman.celabo.org>
In-Reply-To: <3FB6AA8F.37ED6D50@mindspring.com>
References:  <20031114194119.GA94198@madman.celabo.org> <3FB6AA8F.37ED6D50@mindspring.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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 <limits.h> 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



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