Date: Sat, 27 Oct 2001 23:38:56 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: arch@FreeBSD.ORG Subject: illegal &time_t useage in /usr/src Message-ID: <200110280638.f9S6cuA99947@apollo.backplane.com>
next in thread | raw e-mail | index | archive | help
I found 14 instances of illegal time_t casts. They all look very
easy to fix. Most are protocol-related so the correct solution is
truncation. About half assume sizeof(time_t) == sizeof(int). The
other half assume sizeof(time_t) == sizeof(long). I think a couple
even assume sizeof(time_t) == sizeof(int32_t).
I found about a hundred instances of non-fatal time_t truncation
(i.e. program works fine with 64 bit time_t's but will blow up after
2038 (would blow up anyway if not fixed by 2038 no matter what the
platform)). named alone is very amusing code... it squeaks in and
appears to produce runnable (truncation mode) code, but boy is it
a hodge podge of useages.
All told I found numerous instances where time_t was assumed to be
exactly equivalent to <pick just about any int type here>... int, long,
ulong, int32_t, void *, etc... but only 14 where pass-by-reference
cast overrides produced broken code. All the problem areas are minor
and can be fixed in a few minutes. Most of the protocols could even
be upgraded (instead of truncating), though I see no particular reason
to create the incompatibility just now. The elf and a.out timestamps
would have to be left in truncated mode for obvious reasons. Some of
the newer cpio protocols are already good for 11 digits and I've
comitted those changes, as well as some other minor fixups.
The next step is for me to do the syscall roll, test with 32 bit
binaries, then do a full 64 bit buildworld and test a full 64 bit time_t
system. Patches will probably be available for wider testing next week
sometime. I'll also get in touch with the contrib owners in regards to
their time_t issues.
Most of these bugs are bugs that have to be fixed for 64 bit platforms
and/or for 64 bit platforms / 64 bit time_t anyway. I won't actually
commit any IA32/64-bit time_t changes for at least another month,
assuming I can push that part of it through.
-Matt
./contrib/binutils/bfd/elf32-mips.c: unmodified: line 8584 of 9049 [94%]
./contrib/gcc/mips-tdump.c: unmodified: line 776 of 1606 [48%]
./contrib/ipfilter/ipmon.c: unmodified: line 496 of 1282 [38%]
./contrib/ipfilter/ipmon.c: unmodified: line 717 of 1282 [55%]
./contrib/gcc.295/mips-tdump.c: unmodified: line 776 of 1606 [48%]
./crypto/heimdal/appl/dceutils/k5dcecon.c: unmodified: line 186 of 791 [23%]
(krb5_timestamp is a krb5_int32)
./sbin/dump/main.c: unmodified: line 110 of 652 [16%]
/usr/include/protocols/dumprestore.h
(dump header embeds time_t directly, size changes. Not an error
but should probably be converted to truncated form to
maintain backwards dump compatibility)
./sbin/ipfw/ipfw.c: unmodified: line 206 of 2617 [7%]
./sbin/ip6fw/ip6fw.c: unmodified: line 211 of 1407 [14%]
./usr.bin/rusers/rusers.c: unmodified: line 119 of 245 [48%]
(not an error, but size of utmp structure changes)
./usr.bin/rwho/rwho.c: unmodified: line 168 of 221 [76%]
/usr/include/protocols/rwhod.h
out_time is int32_t, rwho assumes it is == time_t, which is
completely illegal.
./usr.sbin/rwhod/rwhod.c: unmodified: line 328 of 745 [44%]
/usr/include/protocols/rwhod.h
wd_recvtime declared as int, assumed to be equiv to time_t,
which is completely illegal.
./usr.sbin/tcpdump/tcpslice/tcpslice.c: unmodified: line 203 of 621 [32%]
./usr.sbin/yppoll/yppoll.c: unmodified: line 91 of 98 [92%]
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?200110280638.f9S6cuA99947>