Re: __TIME_MIN/__TIME_MAX
From: Bruce Evans (bde_at_zeta.org.au)
Date: 11/16/03
- Previous message: Jacques A. Vidrine: "Re: __TIME_MIN/__TIME_MAX"
- In reply to: Jacques A. Vidrine: "Re: __TIME_MIN/__TIME_MAX"
- Next in thread: Jacques A. Vidrine: "Re: __TIME_MIN/__TIME_MAX"
- Reply: Jacques A. Vidrine: "Re: __TIME_MIN/__TIME_MAX"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 16 Nov 2003 23:36:41 +1100 (EST) To: "Jacques A. Vidrine" <nectar@FreeBSD.org>
On Sun, 16 Nov 2003, Jacques A. Vidrine wrote:
> On Sun, Nov 16, 2003 at 04:20:10AM -0600, Jacques A. Vidrine wrote:
> > /* How can this be implemented correctly? */
> > int range_error(long n, time_t t)
> > {
> > return (long)(t = n) == n;
> > }
>
> Hrmp. Because time_t is probably signed, technically this can cause
> `undefined behavior' if the range of `long' is more than the range of
> `time_t' (e.g. on alpha). *sigh*
Actually, it's implementation-defined if time_t is integral (doesn't
matter if it is signed or unsigned) (and the value is not representable).
It's only undefined if time_t is a floating type.
> All I really want to do is correct a parsing bug and at the same time
> eliminate a warning so that I can set WARNS?=1 in libc before the code
> freeze.
You can safely assume that it won't change to floating before the code
freeze :-).
I think (t = n) would cause compiler warnings at higher WARNS levels
if time_t were unsigned. `t == n' certainly would.
`(long)(time_t)n == n' could be used (this is like the above except it
doesn't use a temporary variable. However, the cast to long breaks the
warning about the bug that if n is -1L and time_t is unsigned long, then
the comarison will succeed on 2's complement machines although time_t
cannot represent -1.
Bruce
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
- Previous message: Jacques A. Vidrine: "Re: __TIME_MIN/__TIME_MAX"
- In reply to: Jacques A. Vidrine: "Re: __TIME_MIN/__TIME_MAX"
- Next in thread: Jacques A. Vidrine: "Re: __TIME_MIN/__TIME_MAX"
- Reply: Jacques A. Vidrine: "Re: __TIME_MIN/__TIME_MAX"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|