From owner-freebsd-standards@FreeBSD.ORG Tue Oct 14 01:39:15 2003 Return-Path: Delivered-To: freebsd-standards@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4357216A4B3; Tue, 14 Oct 2003 01:39:15 -0700 (PDT) Received: from mailhub.fokus.fraunhofer.de (mailhub.fokus.fraunhofer.de [193.174.154.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 444A943FAF; Tue, 14 Oct 2003 01:39:13 -0700 (PDT) (envelope-from brandt@fokus.fraunhofer.de) Received: from beagle (beagle [193.175.132.100])h9E8d3303921; Tue, 14 Oct 2003 10:39:05 +0200 (MEST) Date: Tue, 14 Oct 2003 10:39:03 +0200 (CEST) From: Harti Brandt To: Bruce Evans In-Reply-To: <20031014035805.F32262@gamplex.bde.org> Message-ID: <20031014103446.U45269@beagle.fokus.fraunhofer.de> References: <20031013153219.H45269@beagle.fokus.fraunhofer.de> <20031014035805.F32262@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: standards@freebsd.org cc: sparc64@freebsd.org Subject: Re: time_t on sparc64 X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2003 08:39:15 -0000 Thanks for this info Bruce, two questions however: On Tue, 14 Oct 2003, Bruce Evans wrote: BE>On Mon, 13 Oct 2003, Harti Brandt wrote: BE> BE>> I just discovered that time_t is 32-bit on sparc64. One of the problems BE>> is that struct timeval is defined by Posix as BE>> BE>> struct timeval { BE>> time_t tv_secs; BE>> suseconds_t tv_usecs; BE>> }; BE> BE>This is a bug in POSIX. In BSD, tv_secs has type long which may be, BE>and is different from time_t. Why do you think this is a POSIX bug? Aren't we the odd man out? Now we (and MacOS 10) require a workaround for thinks like printf("%s", ctime(tv.tv_secs)); which works perfect on other systems. BE> BE>> but _timeval.h has BE>> BE>> struct timeval { BE>> long tv_secs; BE>> suseconds_t tv_usecs; BE>> } BE>> BE>> This means, that our timeval is not Posix compatible. What is the reason BE>> for time_t not beeing a long on sparc64? BE> BE>time_t was used in some data structures whose layout shouldn't be changed BE>even for new arches. Mainly in ufs in Lite2: BE> BE>%%% BE>ffs/fs.h: time_t fs_time; /* last time written */ BE>ffs/fs.h: time_t cg_time; /* time last written */ BE>ffs/fs.h: time_t cg_time; /* time last written */ BE>lfs/lfs.h: time_t bi_segcreate; /* origin segment create time */ BE>ufs/quota.h: time_t dqb_btime; /* time limit for excessive disk use */ BE>ufs/quota.h: time_t dqb_itime; /* time limit for excessive files */ BE>%%% BE> BE>These are now: BE> BE>%%% BE>ffs/fs.h: int32_t fs_old_time; /* last time written */ BE>ffs/fs.h: ufs_time_t fs_time; /* last time written */ BE>ffs/fs.h: int32_t cg_old_time; /* time last written */ BE>ffs/fs.h: ufs_time_t cg_time; /* time last written */ BE>/dev/null: time_t bi_segcreate; /* origin segment create time */ BE>ufs/quota.h: int32_t dqb_btime; /* time limit for excessive disk use */ BE>ufs/quota.h: int32_t dqb_itime; /* time limit for excessive files */ BE>%%% BE> BE>I.e., int32_t is now not mispelled time_t in f^Hufs1 and Y2.038K bugs are BE>fixed in ffs2 except for quotas. BE> BE>ffs2 also parametrizes timestamps in inodes better: BE> BE>%%% BE>ufs/dinode.h:typedef int64_t ufs_time_t; BE>ufs/dinode.h: ufs_time_t di_atime; /* 32: Last access time. */ BE>ufs/dinode.h: ufs_time_t di_mtime; /* 40: Last modified time. */ BE>ufs/dinode.h: ufs_time_t di_ctime; /* 48: Last inode change time. */ BE>ufs/dinode.h: ufs_time_t di_birthtime; /* 56: Inode creation time. */ BE>ufs/dinode.h: int32_t di_mtimensec; /* 64: Last modified time. */ BE>ufs/dinode.h: int32_t di_atimensec; /* 68: Last access time. */ BE>ufs/dinode.h: int32_t di_ctimensec; /* 72: Last inode change time. */ BE>ufs/dinode.h: int32_t di_birthnsec; /* 76: Inode creation time. */ BE> BE>[Note that these aren't in a timespec struct, POSIX or otherwise, since the BE>struct would give MD packing which happens to be inefficient in most cases.] BE> BE>ufs/dinode.h: int32_t di_atime; /* 16: Last access time. */ BE>ufs/dinode.h: int32_t di_atimensec; /* 20: Last access time. */ BE>ufs/dinode.h: int32_t di_mtime; /* 24: Last modified time. */ BE>ufs/dinode.h: int32_t di_mtimensec; /* 28: Last modified time. */ BE>ufs/dinode.h: int32_t di_ctime; /* 32: Last inode change time. */ BE>ufs/dinode.h: int32_t di_ctimensec; /* 36: Last inode change time. */ BE> BE>[Y2.038K bugs are still in ffs1.] BE>%%% BE> BE>To change time_t to 64 bits, all in-use non-transient data structures BE>need to be changed similarly. I guess we have to do this work before 2038, don't we? If we don't do it before 5.2 we have to stick with this until 6.0. Correct? harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private brandt@fokus.fraunhofer.de, harti@freebsd.org