Date: Sun, 3 Jun 2001 00:24:13 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: obrien@FreeBSD.org Cc: Matt Dillon <dillon@earth.backplane.com>, David Wolfskill <david@catwhisker.org>, arch@FreeBSD.org, freebsd-standards@bostonradio.org Subject: Re: time_t definition is wrong Message-ID: <p05100e03b73f681ef31b@[128.113.24.47]> In-Reply-To: <20010602125856.L31257@dragon.nuxi.com> References: <200106012318.f51NI8w38590@bunrab.catwhisker.org> <200106020823.f528N5O98998@earth.backplane.com> <20010602085237.A73968@dragon.nuxi.com> <200106021739.f52Hd9V03943@earth.backplane.com> <p05100e0fb73ee9d458f7@[128.113.24.47]> <20010602124907.G31257@dragon.nuxi.com> <p05100e11b73ef4f9f5d1@[128.113.24.47]> <20010602125856.L31257@dragon.nuxi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 12:58 PM -0700 6/2/01, David O'Brien wrote: >On Sat, Jun 02, 2001, Garance A Drosihn wrote: > > ...also, in situations where "we can't agree there is a problem", >> I thought we were supposed to favor the status quo (ie, pre-update) >> over rushing in to fix something which we can not agree is broken. > >We've just *started* the disucussion. If we can decide on it in >48-hours why toss the repo back and forth. I didn't mean to trigger an impassioned debate over this on the freebsd standards list. It was just that I suspect that any "standards checking" will take a little time. Time enough to read up on various positions, or send a few messages to other members of Posix to try to get a good, consistent answer to this issue. As such, I assumed it would take more than 48 hours, particularly since the issue has popped up on a weekend. This is why it seemed best to back out the update. Right or wrong, time_t has been the way it is for a long time, and there is no burning need to have it changed right this minute (even if it is the right change). The other side of the debate should also note that I (personally) really do not have a clue which definition is the best. All I'm saying is that I would think we might be better off waiting a little longer before deciding which change (if any) is the best change. We are talking about a change to a Standard system type, which will effect programs across-hardware-platforms and across- operating-systems. No matter WHICH way we address this, there is going to be a little work involved, and we might as well try to minimize how many times we have to redo that work. If anyone DID want my opinion, the real problem here is the printf %-codes. Here we have include files which explicitly use a non-size-specific type (ie, they say 'size_t', instead of 'int'), but printf-commands have to know the exact size of that type. Flawed by design. But then, no one did ask me... -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu 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?p05100e03b73f681ef31b>