"Jonathan Turkanis" <technews@kangaroologic.com> wrote in message 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?
I started to answer your question as asked, but then realized it isn't my opinion that counts, but rather the LWG's collective opinion, which will be heavily influenced by the implementers. So maybe what we ought to do over the next two weeks is to build up a list of questions, then ask the LWG in Lillehammer for their preferences. Action plan for the next couple of days is to read chapter 27, and try to identify as many issues as possible. --Beman