Date: Sat, 27 Oct 2001 08:45:45 -0700 (PDT) From: John Baldwin <jhb@FreeBSD.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: arch@FreeBSD.ORG, des@ofug.org, Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Subject: Re: 64 bit times revisited.. Message-ID: <XFMail.011027084545.jhb@FreeBSD.org> In-Reply-To: <200110270623.f9R6NLk43302@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 27-Oct-01 Matthew Dillon wrote: > >:In article <xzpwv1hq2ck.fsf@flood.ping.uio.no> you write: >:>Chapter and verse, please. Not just a repetition of what somebody >:>else says may or may not be in C90. >: >:Cheap shot. See C90 defect report #67, >:<http://wwwold.dkuug.dk/JTC1/SC22/WG14/www/docs/dr_067.html>. >:Although neither time_t nor ``arithmetic type'' is not explicitly >:mentioned in the defect report, the answers to Clive Feather's final >:two questions apply. > > Take a look at this: > > http://wwwold.dkuug.dk/JTC1/SC22/WG14/www/docs/summary.htm > > This is the defect list for C99. It directly contradicts the reasoning > in C90 defect report #67. Read #201 and #204. In the #201 the submitter > tried to change the standard to require that size_t be no wider then > unsigned long, but there was NO consensus to make this change. In > #204 the submitter wants to explicitly allow size_t to be a 'long long'. > #204 was incorporated into TC1. I found TC1 and looked it up, and > it's there: > > "The types used for size_t and ptrdiff_t should not have an > integer conversion rank greater then that of signed long unless the > implementation supports objects large enough to make this necessary" > > Obviously they have caved in. 'long long' is being treated as an > integral type. In a draft I found it defined as being an > 'extended integral type'. This implies that it can be used for time_t. > Unless something explicitly forbids it I think going to 64 bit time_t's > in 5.0 is the correct action to take. > > ... still waiting for someone who has the latest C99 spec to look this > stuff up :-) Matt, just because C99 has changed doesn't mean we have to break C90. This is the difference between your baseline that you support vs. the newest stuff you support. Here's an example: for 4.x-stable, 4.1 is our baseline. This means that kernel modules, binaries, etc. from 4.1 should work on 4.4. Now, this doesn't mean that a program written for 4.4 can't use new features in 4.4, but 4.4 should not break backwards compatibility such that a 4.1 program no longer runs. Does this make sense? Ok, now go back through that and do s/4.1/C90/ and s/4.4/C99/. C99 is rather new to be requiring that all userland programs in the world be up to date to it, so C90 is a better baseline support. So you can add the extensions of C99 so a C99 program can run, but you can't break C90 compatibility by changing arbitrary things until we have actually changed our baseline from C90 to C99. It is probably too early to do that. Then again, you _did_ just break file system module compatibility on 4.x-stable, so maybe this is a foreign concept to you. However, you did justify that by saying there weren't any fs modules around, which makes me think you _do_ understand this issue. -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ 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?XFMail.011027084545.jhb>