"Jonathan Turkanis" <technews@kangaroologic.com> skrev i meddelandet news:d22hfp$7e9$1@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