From: Bo Persson (bop_at_[hidden])
Date: 2005-03-26 05:14:19
"Jonathan Turkanis" <technews_at_[hidden]> skrev i meddelandet
news:d22hfp$7e9$1_at_sea.gmane.org...
>
> 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
>
Doesn't this run into the same problems as the original standard does -
what to do when there isn't an integral type large enough? The current
library definition uses type long, because that is as wide as it gets!
Bo Persson