Thanks for the clarification.
And I agree, 64-bit time_t's should automatically presume that large
file offsets are *also* in use.
I don't think 64-bit time_t's make any of the caveats for large file
offsets worse. I.e. I think the same NOTES would apply to both cases.
-- Garrett
Don Cragun wrote:
> >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
>>
