RE: Large file iostreams

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

Nathan Myers wrote:
> No, it's a defect.  At least at one time there was text in the
> standard that required that stateT (and by extension mbstate_t)
> could be initialized with stateT(), and that matched the state
> at the beginning of a sequence.  I don't find that text now,
> and it's essential.

I think you have found a different problem.  The problem I
described was that given the code:

  fpos<stateT> p = 0;
  stateT s = p.state();

The standard doesn't state what the value of s is supposed to be.
This may not be a defect since almost nothing can be done with p
anyway.

The problem I think you are referring to is that the standard
gives this precondition for codecvt::do_in/do_out:

  state initialized, if at the beginning of a sequence

But it is never specified what is meant by "initialized".
I agree that this seems to be a real problem when using codecvt
directly.

However, I don't think this matters for basic_filebuf:
The only functions that seem to need to know what the
initial state is supposed to be are basic_filebuf::open() and
basic_filebuf::seekoff(). These are both provided by the
implementation, and implementors presumably know how to
intitialize mbstate_t (since it's an implementation-defined
type).

There is no need for the standard to say how to initialize other
state_types, since the use of those with basic_filebuf is
implementation defined.

> Without it, all the multibyte stuff is
> meaningless.

Not really. It is possible to write codecvt facets for utf-8
and other stateless encodings without ever using the conversion
state.

There doesn't seem to be any real requirement that stateful
encodings should be supported. Support for stateful encodings
adds much complexity to basic_filebuf, so this may be by design.

Regards,
Petur