>From psarc-intern-list-request at sun.com Fri Jun 20 09:42:26 2008 >Date: Fri, 20 Jun 2008 17:40:40 +0100 >From: Darren J Moffat <Darren.Moffat at sun.com> >Subject: Re: Spec update and draft opinion available for 2008/351 - Switch > SPARC GNU coreutils+bash from 32 to 64bit >To: "Garrett D'Amore" <gdamore at sun.com> >Cc: John Plocher <plocher at sac.sfbay.sun.com>, psarc-ext at sun.com >MIME-version: 1.0 >Content-transfer-encoding: 7BIT >User-Agent: Thunderbird 2.0.0.14 (X11/20080507) > >Garrett D'Amore wrote: >> Yes. Was large file support a POSIX issue, though? > >Yes.
Not really. It was, and is, a C standard issue. The C standard's function prototypes for fseek() and ftell() specify that the file offset argument or return value is of type "long int" rather than the "off_t" type used by POSIX for lseek() and tell(). And, in an ILP32 environment, you can't use c89 to build an LFS application (because the 1989 ANSI C standard and the 1990 ISO C standard don't have the "long long" data type and don't allow it as an extension in standard conforming compilations. > >>> >>> I think unless the advise makes it clear that this is a standards >>> issue that won't be known and the impact/scope of the project will not >>> necessarily be understood by the recipients of the advice. >> >> Hmmm... do you have specific language you'd like to add? > >Not of the top of my head but if necessary I could craft it though I >think Don would be the best candidate to do this. This is not an API standards issue (except for applications that want to simultaneously conform an environment with a 64-bit time_t and to XPG3, POSIX.1-1988, or the 1989/1890 C standards. All of the affected interfaces specify time_t and implmentations are free to choose any integral type large enough to hold the desired range of timestamps. Backwards compatibility and ABIs are the issue here; not the current C, POSIX, and SUS standards. Note: Don't shoot the messenger for the following; I'm just reporting history... Tim Marsland decided that Solaris systems would not support 64-bit time_t's in 32-bit apps when we did our first 64-bit OS. IBM has already made access to 64-bit time_t's available to 32-bit applications. I think HP has also gone down this route, but I'm not sure. (HP supported Sun's position for a while, but I think they gave in later.) This issue comes up again every year or so, but Sun's consistent message so far has been that applications that want a 64-bit time_t should be built as LP64 (not ILP32) applications. (The combinations between various compilation modes and libraries [especially 3rd party libraries] makes providing a 64-bit time_t to 32-bit applications a much bigger project than it might seem at first glance. Note the disclaimers in the NOTES section of the lfcompile(5) man page; the restrictions would be worse for applications wanting a 64-bit time_t in an LFS environment. [I don't think it makes any sense at all to even consider providing a 64-bit time_t in an environment that doesn't also have a 64-bit off_t!]) - Don > > >-- >Darren J Moffat
