[boost] Re: Boost policy on relying on stdlibraryimplementationdefined behaviour

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