Large file iostreams

[Pétur Runólfsson <peturr02 at ru dot is>]

Hi,

In message
http://gcc.gnu.org/ml/libstdc++/2003-07/msg00193.html
Nathan Myers wrote:
> Indeed.  That seems like another defect, or two.  Is anybody getting 
> these written down? :-)  I propose not to adopt those defects into 
> libstdc++, since the correct resolution seems pretty obvious.

I came up with this list last night (this includes already reported
defects):

21.1.2 p4: state_type needs to be DefaultConstructible and Assignable
to be usable as a template parameter for fpos<>. (DR 352)

21.1.3.1 p3, 21.1.3.2 p2, D.6 p6: streampos and wstreampos are not
implementation-defined, since both are required to be fpos<mbstate_t>

21.1.3.2 p3: streampos and wstreampos can't be different. (DR 57)

27.4.3: No requirements are given for stateT. (DR 352)

27.4.3, 27.5.2: streamoff isn't required to be CopyConstructible, yet
this is necessary for pass-by-value in basic_streambuf::pubseekoff.

27.4.3.2: p, q and o are values, but the expressions q = p + o,
p += o, q = p - o, p -= o and o = p - q seem to require l-values.

27.4.3.2: The return types fpos and OFF_T don't make sense, fpos
is not a type and OFF_T is not defined in this subclause.

27.4.3.2: The return values and types of the expressions p + o, p - o
and p - q are not given.

27.4.3.2: The return values of the expressions q = p + o, p += o,
q = p - o, p -= o, o = p - q are not given, only the types.

27.4.3.2: The postcondition p == P(i) for the expression P(i) implies
that p == q for all p and q.

27.6.1.3 p37, 27.6.2.4 p1: The literal 0 is passed as the first argument
of basic_streambuf::pubseekoff, but 27.4.3 doesn't require an implicit
conversion from int to streamoff.

27.7.1.3 p12, D.7.1.3 p13, p14: The expressions newoff + off and
xbeg + newoff + off are used, but the type of newoff isn't given and
27.4.3 only requires p + off where p is fpos<stateT>.

27.8.1.4 p11: Uses the expression width * off where width is of type int
and off of type off_type, yet this is not required by 27.4.3.

D.7.1.3 p17: Uses sp.offset() where sp is of type streampos, but no
such member is defined in 27.4.3.

And here are a few more that are just bad wording or have easy
workarounds:

27.2 p8: fpos<charT> should be fpos<stateT> (the name of the template
parameter may be significant, see 27.1.2).

27.4.1 p2, footnote: conversion to/from streamoff also requires
streamsize to be signed, also the return value of showmanyc may be
negative.

27.4.3: streamoff and fpos<stateT> are not required to be
DefaultConstructible. A workaround is to use streamoff(0) and
fpos<stateT>(streamoff(-1)) to get default values.

27.4.3: streamoff isn't required to be Assignable.

27.7.1.3 p13, D.7.1.3 p15: Uses newoff, but it's a different newoff
from the one in 27.7.1.3 p12 and D.7.1.3 p13.

And elsewhere, I wrote:
> Nathan Myers wrote:
> >> #include <ios>
> >> int main()
> >> {
> >>   std::streamoff m, n;
> >>   std::streamoff o(m - n);
> >> }
> >
> > Uh-oh.  If it's a conforming program, then adding overloads that make
> > it _not_ truncate its result is not allowed.  That looks like a defect.
> 
> I agree.

I'm not so sure about this one any more. Since streamoff is an
implementation-defined type, surely it is implementation-defined
whether this program compiles, and if so, what it's semantics are.

I think the correct solution is to just Do The Right Thing by
default, point out the "implementation-defined" if someone complains
that this is not conforming, and possibly provide a "pedantic" mode
that provides only what the standard requires (which is almost
nothing).

Regards,
Petur