IOStreams Issues List                      X3J16/95-0034
  Library Clause 27                          WG21/N0634
  ---------------------------------------
 
  by John Hinke, Rogue Wave Software
    hinke@roguewave.com
 
  This is a list of IOStreams issues, questions, problems that
  have come up from either the reflector, e-mail, or other sources.
 
 
   Work Group:     Library Clause 27
   Issue Number:   001
   Title:          Do ios type classes access the streambuf on destruction...
   Section:        27
   Status:         active
   Description:
 
    Angelika Langer asks,
      "Is it correct that all classes in the 'ios' class family which
      do not provide the stream buffer themselves, i.e. the buffer
      is externally provided, do not access the stream buffer on
      construction or destruction?
      This is explicitly stated for ~istream() and ~ostream() in the draft,
      and will be added for ~ios() as well, as far as I've gathered."
 
   Possible Resolution:
   Requestor:      Angelika Langer (Angelika.Langer@mch.sni.de)
   Owner:
   Emails:
   Papers:
 
  -----------------------------------------------------------------------
 
   Work Group:     Library Clause 27
   Issue Number:   002
   Title:          Do streambuf classes access the buffer on destruction...
   Section:        27
   Status:         active
   Description:
 
    Angelika Langer asks,
      "Does the same hold for all classes in the 'streambuf' family in cases
      when the character buffer is provided externally via setbuf() or
      pubsetbuf()?  (Access on construction is no issue here, as there is
      no constructor which allows attaching the character buffer. So the
      question is only about access on destruction.)"
 
   Possible Resolution:
   Requestor:      Angelika Langer (Angelika.Langer@mch.sni.de)
   Owner:
   Emails:
   Papers:
 
  -----------------------------------------------------------------------
 
   Work Group:     Library Clause 27
   Issue Number:   003
   Title:          input/output of wchar_t's and char's
   Section:        27
   Status:         active
   Description:
 
      char    c;
      wchar_t wc;
 
      cout << wc;  // ERROR converted to int?
      wcout << c;  // converted to int?  Not what I want
 
      Should this be possible?
 
   Possible Resolution:
 
   Requestor:      John Hinke (hinke@roguewave.com)
   Owner:
   Emails:
   Papers:
 
  -----------------------------------------------------------------------
   Work Group:     Library Clause 27
   Issue Number:   004
   Title:          public typedefs in the interface
   Section:        27...
   Status:         active
   Description:
 
      All of the IOStreams classes have a public section that only contains
      either typedefs for abreviation, or helper functions that are not
      part of the interface.  Should these typedefs and functions be moved
      to the private section.  An example is:
 
        typedef charT   char_type;
        static int_type eof() { return traits::eof(); }
 
   Possible Resolution:
 
      Remove the static functions.  They are not needed, and they are
      error prone.
 
        // class ios
      bool ios::eof();
 
        // class istream
      static int_type eof() { return traits::eof(); }
 
   Requestor:      John Hinke (hinke@roguewave.com)
   Owner:
   Emails:
   Papers:
 
  -----------------------------------------------------------------------
   Work Group:     Library Clause 27
   Issue Number:   005
   Title:          no op<<(unsigned char_type *), and signed char_type *
   Section:        27.2.4
   Status:         active
   Description:
 
      There are no operator<<() for unsigned char_type *, and
      signed char_type *.  There are corresponding functions in istream.
 
   Possible Resolution:
 
   Requestor:      John Hinke (hinke@roguewave.com)
   Owner:
   Emails:
   Papers:
 
  -----------------------------------------------------------------------
   Work Group:     Library Clause 27
   Issue Number:   006
   Title:          unsigned charT issues
   Section:        27
   Status:         active
   Description:
 
      There needs to be a way to insert and extract unsigned charT's
      from a stream.  Where charT is the template parameter.
 
      Also, all of the unformatted input/output functions: read, write,
      get, put, etc...
 
   Resolution:
   Requestor:      John Hinke (hinke@roguewave.com)
   Owner:
   Emails:
   Papers:
 
  -----------------------------------------------------------------------
   Work Group:     Library Clause 27
   Issue Number:   007
   Title:          istream::isfx
   Section:        27.2.2.1.4
   Status:         active
   Description:
 
      What is the purpose of this function?  The WP says all it does is
      "returns".  Should it do something more?  Or is it implementation
      defined!
 
      See Also #22
 
   Possible Resolution:
 
   Requestor:      John Hinke (hinke@roguewave.com)
   Owner:
   Emails:
   Papers:
 
  -----------------------------------------------------------------------
   Work Group:     Library Clause 27
   Issue Number:   008
   Title:          ios_base::exceptions(...)
   Section:        27.1...
   Status:         active
   Description:
 
      The ios_base::exceptions(iostate except_arg) function calls a member
      of basic_ios, which isn't accessible.  It calls basic_ios::clear.
 
   Possible Resolution:
 
   Requestor:      John Hinke (hinke@roguewave.com)
   Owner:
   Emails:
   Papers:
 
  -----------------------------------------------------------------------
   Work Group:     Library Clause 27
   Issue Number:   009
   Title:          ios_base::setfill
   Section:        27.1...
   Status:         active
   Description:
 
      The ios_base::setfill function returns a type that is dependent upon
      the template type; however, ios_base is a non-templatized class.
 
   Possible Resolution:
 
   Requestor:      John Hinke (hinke@roguewave.com)
   Owner:
   Emails:
   Papers:
 
  -----------------------------------------------------------------------
   Work Group:     Library Clause 27
   Issue Number:   010
   Title:          istream::isfx
   Section:        27.2.2.1.4
   Status:         active
   Description:
 
      There is mention of an imbued locale for streambuf in the WP, but
      there isn't any mention of it in the class.
 
      See Also #22
   Possible Resolution:
 
   Requestor:      John Hinke (hinke@roguewave.com)
   Owner:
   Emails:
   Papers:
 
  -----------------------------------------------------------------------
   Work Group:     Library Clause 27
   Issue Number:   011
   Title:          basic_streambuf::stossc()
   Section:        27.2.1.2
   Status:         active
   Description:
 
    Bernd Eggink says,
      "The function is missing, and will break a lot of code."
 
   Possible Resolution:
 
   Requestor:      Bernd Eggink (admin@rzaix13.rrz.uni-hamburg.de)
   Owner:
   Emails:
   Papers:
 
  -----------------------------------------------------------------------
   Work Group:     Library Clause 27
   Issue Number:   012
   Title:          basic_streambuf::sputc(int c)
   Section:        27.2.1.2.13
   Status:         active
   Description:
 
     Bernd Eggink says,
       "I think the parameter should be "int_type" instead of "int".
       May this be called with parameter eof()? If so, what will happen?
       What is the effect of calling sputc() with an arbitrary int
       parameter?"
 
   Possible Resolution:
 
     His proposal:
       "A consistent solution would be to change 27.2.1.2.13 like this:
 
  	int_type sputc(int_type c);
 
  	If the output sequence does not have a write position available,
  	returns overflow(c). Otherwise, if c != eof(), returns
  	(*pnext++ = (char_type)c). Otherwise returns a value != eof()."
 
   Requestor:      Bernd Eggink (admin@rzaix13.rrz.uni-hamburg.de)
   Owner:
   Emails:
   Papers:
   See Also: 013
 
  -----------------------------------------------------------------------
   Work Group:     Library Clause 27
   Issue Number:   013
   Title:          basic_streambuf::sputc(...)
   Section:        27.2.1.2.13
   Status:         active
   Description:
 
   Possible Resolution to 012:
 
      The return type should clearly be int_type.  I think that was
      just overlooked in the templatization.  I think the argument
      type should be char_type.
 
      For ordinary char streambuf's sputc(-1) is supposed to insert
      0xff.  At least that is what it did in the original implementation.
      Note that under your description the function would do different
      things depending on whether or not a write position is available.
      The originaly implementation does overflow(zapeof(c)) when it calls
      overflow.  Zapeof was a macro that corresponds to the version of
      not_eof accepted at VF.
 
          int_type not_eof(char_type) ;
 
      So I think we should say it calls
 
          overflow(not_eof(char_type))
 
      in case a write position isn't available
 
   Requestor:      Jerry Schwarz (jss@declarative.com)
   Owner:
   Emails:
   Papers:
   See Also: 012
 
  -----------------------------------------------------------------------
   Work Group:     Library Clause 27
   Issue Number:   014
   Title:          basic_ functions
   Section:        27.1
   Status:         active
   Description:
 
      What is the purpose of the basic_ functions (basic_dec,
      basic_oct...)?  The same purpose can be achieved without using
      the basic_ prefix.
 
   Possible Resolution:
 
   Requestor:      John Hinke (hinke@roguewave.com)
   Owner:
   Emails:
   Papers:
 
  -----------------------------------------------------------------------
   Work Group:     Library Clause 27
   Issue Number:   015
   Title:          istream::seekg(), tellg()
   Section:        27.2.2.1
   Status:         active
   Description:
 
      These functions were missing from the WP.
 
        pos_type         basic_istream::tellg();
        basic_istream&   basic_istream::seekg(pos_type&);
        basic_istream&   basic_istream::seekg(off_type&,
                                              ios_type::seekdir);
 
        pos_type         basic_ostream::tellp();
        basic_ostream&   basic_ostream::seekp(pos_type&);
        basic_ostream&   basic_ostream::seekp(off_type&,
                                              ios_type::seekdir);
 
   Possible Resolution:
 
   Requestor:      John Hinke (hinke@roguewave.com)
   Owner:
   Emails:
   Papers:
  -----------------------------------------------------------------------
   Work Group:     Library Clause 27
   Issue Number:   016
   Title:          basic_[i|o]ostream::operator<<(basic_streambuf&)
   Section:        27.2.2.1, 27.2.4.1
   Status:         active
   Description:
 
      The original iostreams contained functions
          istream& istream::operator>>(streambuf*)
          ostream& ostream::operator<<(streambuf*)
 
      I see in the current draft that they have been changed to take
      references instead of pointers.
 
   Possible Resolution:
 
   Requestor:      Steve Clamage (stephen.clamage@eng.sun.com)
   Owner:
   Emails:
   Papers:
 
  -----------------------------------------------------------------------
   Work Group:     Library Clause 27
   Issue Number:   017
   Title:          strstream constructors
   Section:        27.4.1.1
   Status:         active
   Description:
 
      Bernd Eggink says,
        "The effect of basic_ios::ate should be mentioned. A behavior
        corresponding to basic_filebuf::open() would be desirable: If
        the bit basic_ios::app is set, insertions take place at the end
        of the string. Maybe this is a major issue, but I think it
        should be considered for the sake of consistency."
 
      This should be considered for basic_strstreambuf, and
      basic_ostrstream
 
   Possible Resolution:
 
   Requestor:      Bernd Eggink (admin@rrz.uni-hamburg.de)
   Owner:
   Emails:
   Papers:
  -----------------------------------------------------------------------
   Work Group:     Library Clause 27
   Issue Number:   018
   Title:          basic_stringbuf constructor
   Section:        27.4.2.1
   Status:         active
   Description:
 
      Same problem as Issue Number 017.
 
   Possible Resolution:
 
   Requestor:      Bernd Eggink (admin@rrz.uni-hamburg.de)
   Owner:
   Emails:
   Papers:
  -----------------------------------------------------------------------
   Work Group:     Library Clause 27
   Issue Number:   019
   Title:          basic_ostream::operator<<(char)
   Section:        27.2.4.2.2
   Status:         active
   Description:
 
      Bernd Eggink says,
        "I think that this function should behave like all other formatted
        inserters with respect to width, fill and padding."
 
   Possible Resolution:
 
   Requestor:      Bernd Eggink (admin@rrz.uni-hamburg.de)
   Owner:
   Emails:
   Papers:
 
  -----------------------------------------------------------------------
   Work Group:     Library Clause 27
   Issue Number:   020
   Title:          input of hex values
   Section:        27.1.3.2.4, Table 95
   Status:         active
   Description:
 
      If you output hex values with:
 
        cout << showbase << hex << i;  // 0xabcd
 
      When it comes to reading this input back in:
 
        cin >> showbase >> hex >> i; // doesn't work!
 
      The hex manipulator says to only read "hex" values.  Is this
      correct?  Should this code fragment work?  What about:
 
        cout << showbase << hex << i;  // 0xabcd
          ...
        cin >> hex >> i;
 
      The table says that it converts integer input/output in
      hexadecimal base
 
      The same issues follow with oct, and with showpos.
 
   Possible Resolution:
 
   Requestor:      John Hinke (hinke@roguewave.com)
   Owner:
   Emails:
   Papers:
 
  -----------------------------------------------------------------------
   Work Group:     Library Clause 27
   Issue Number:   021
   Title:          default locale arguments
   Section:        27.2.2
   Status:         active
   Description:
 
      Default locale arguments for stream constructors.
 
      istream and ostream constructors (and all derivations)
      should have a default locale argument, in the manner of:
 
        obogusstream(const char* name, locale const& = locale::classic());
 
      or perhaps
 
        obogusstream(const char* name, locale const& = locale());
 
    Norihiro Kumagai <kuma@slab.tnr.sharp.co.jp> replies:
 
      In order to cordinate the C-language locale model, I believe that the
      default locale value should not be 'locale::classic ()', what we call
      "C" locale, but be 'locale::global()', the current global locale.
 
   Possible Resolution:
 
   Requestor:      Nathan Myers (myersn@roguewave.com)
   Owner:
   Emails: c++std-lib-3389, c++std-lib-3390, c++std-lib-3394
   Papers:
  -----------------------------------------------------------------------
   Work Group:     Library Clause 27
   Issue Number:   022
   Title:          [io]{pfx|sfx} and exceptions
   Section:        27.2.2.1, 27.2.4.1
   Status:         active
   Description:
 
      The members ipfx()/opfx() and isfx()/osfx() of the streams are
      not compatible with exceptions.  We need to eliminate them in favor
      of member classes whose constructor/destructor perform the same
      actions, in the manner of custodian classes.
 
   Possible Resolution:
 
   Requestor:      Nathan Myers (myersn@roguewave.com)
   Owner:
   Emails:
   Papers:
 
  -----------------------------------------------------------------------
   Work Group:     Library Clause 27
   Issue Number:   023
   Title:          ostream::operator<<(void *)
   Section:        27.2.4.1
   Status:         active
   Description:
 
      ostream& operator << (ostream&, void *)
 
      should take `const volatile void *' rather than `void *'.
 
   Possible Resolution:
 
   Requestor:      Fergus Henderson (fjh@munta.cs.mu.oz.au)
   Owner:
   Emails:
   Papers:
  -----------------------------------------------------------------------
   Work Group:     Library Clause 27
   Issue Number:   024
   Title:          ostream::operator<<(streambuf&)
   Section:        27.2.4.1
   Status:         active
   Description:
 
      ostream& operator << (ostream&, basic_streambuf&)
 
      should take `const basic_streambuf&' rather than `basic_streambuf&'.
 
   Possible Resolution:
 
   Requestor:      John Hinke (hinke@roguewave.com)
   Owner:
   Emails:
   Papers: