[boost] Re: Boost policy on relying on std libraryimplementationdefined behaviour

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2005-03-25 21:26:56

Beman Dawes wrote:
> "Jonathan Turkanis" <technews_at_[hidden]> wrote in message
> news:d1v087$6r0$1_at_sea.gmane.org...
>> Hi All,
>>
>> Is there a reason to avoid providing a uniform interface to
>> implementation-defined standard library features?
>>
>> One of the most often heard complaints about the standard iostreams
>> library is that there is no portable way to seek within a file stream using
>> large (64-bit) offsets.
>
> I really want to see this fixed in the standard library. Any interest
> in getting a proposal together?

Yes, definitely.

> It seems to me the first step is to fix the <cstdio> stuff inherited from
> the C library. An easy way to do that is to propose the addition of
> fseeko and ftello functions. They are already provided on Solaris,
> FreeBSD, HP-UX, NetBSD, OpenBSD, and HP/Compaq/DEC Alpha OSF/1. SGI
> IRIX offers the same functionality, but named fseek64() and
> ftell64(). Apparently Linux is the only weak spot in the POSIX world.
> The functionality is trivial to provide under modern flavors of
> Windows. (Thanks to Nelson Beebe for survey of POSIX practice.)

Good survey.

> I haven't given much thought to changes that would be required for
> iostreams yet.

Two possibilities I can think of are as follows (I'm writing this off the top of
my head -- I'll need to give it more thought):

1. require streamoff (and the various member types, such as
char_traits<>::off_type which have the same requirements as streamoff) to
satisfying whatever requirements you would impose on the second parameter of
fseeko.

2. Change the legend to Table 88 (27.4.3.2/1) so that
  - instead of referring to type streamoff, "O" refers to an integral type
satisfying whatever requirements you would impose on the second parameter of
fseeko.
  - "o" refers to a value of type "O"

Option 1 is more straightforward, but could require some standard libraries
(notably Dinkumware) to change the size of their streamoff type even though
their streampos already provides adequate large-file support. Standard libraries
which already provide a large streamoff would need no change.

Option 2 would allow standard libraries which provide a small streamoff but a
streampos capable of storing large values to conform by providing a streampos
constructor callable with a single parameter of type "O" and by replacing the
conversion to streamoff with a conversion to "O".

How do these strike you?

Jonathan