Topic: bug in most iostream implementations


Author: myersn@hobo.ECE.ORST.EDU (Nathan Myers)
Date: 15 Apr 93 04:19:21 GMT
Raw View
Here's some mail I exchanged with Jerry Schwarz about a common
bug in implementations of iostreams.

> From: orstcs!lucid.com!jss (Jerry Schwarz)
> Subject: xalloc() in C++ draft standard
>
> > I'm trying to use ios::xalloc()/pword().  I have seen a man page
> > somewhere (old libg++ maybe?) that says the value referenced by
> > pword() or iword() is initialized to zero before the first call
> > to one of those functions on a particular stream.  I have been unable
> > to find such a claim in either Lucid's or Sun's C++ documentation,
> > nor such behavior in Sun's implementation.  However, the example
> > in your "iostream Examples" seems to depend on this behavior.
> >
> > Does the standard specify that user state variables in streams
> > are initialized to zero?  If not, it seems to me a module cannot
> > reliably discover whether its "word" has been set in any particular
> > stream, and so cannot use this feature.
> >
>
> The current working paper explicitly requires initialization to zero,
> precisely for the reason you indicate.  Note that the current working
> paper eliminates the union.  The iword and pword arrays are now
> independent.
>
> I'm afraid I can't shed much light on the history because I don't
> remember when I realized initialization to zero was neccessary.
> Apparently after I did the original implementation.  You're right that
> the AT&T library (and Sun's port) doesn't initialize to zero.
> Lucid's documentation is just a copy of AT&T's (as I believe is Sun's).
>
> I think failure to initialize can best be characterized as a bug. [...]
>
>    -- Jerry

The bug is particularly likely to appear in libraries ported from AT&T.
I found it in libraries for Sun C++ 3.0, HP C++ 3.0, and IBM's xlC.  It
seems to be fixed in Silicon Graphics C++ 3.0, as well as in Borland C++
3.1 and Microsoft C++ 7.0.  Curiously, FSF/Gnu seems to have entirely
eliminated support for ios::xalloc() from libg++.  (Can anybody say why?)

Here is code that usually detects the bug:

#include <iostream.h>
int main()
{
  int i = ios::xalloc(), j = ios::xalloc(), k = ios::xalloc();
  if (cin.pword(i) || cout.pword(i) || cerr.pword(i) ||
      cin.pword(j) || cout.pword(j) || cerr.pword(j) ||
      cin.pword(k) || cout.pword(k) || cerr.pword(k)) {
    cout << "ios::pword() is broken.\n";
    return 1;
  }
  else
    return 0;
}

I believe the xalloc() feature will become dramatically more
important as internationalization support becomes more widespread.

Nathan C. Myers
myersn@roguewave.com   [include standard disclaimers here]