problem reports

[Dietmar Kuehl <dietmar_kuehl at yahoo dot com>]

Hi,

in the discussion of the quality of different standard C++ library
implementation I was asked to report the bugs I have discovered in
libstdc++-v3. Here is a report of a bunch of problems. Since I consider
libstdc++ to be a competition to my own implementation, CXXRT, I'm not
really willing to spent to much time on this. However, the problem
reports and the results of my testsuite should show that I'm not just
making up things and I recommend that someone interested in pushing
libstdc++ should use my testsuite on libstdc++ to track down more
problems: The testsuite is freely available and can be downloaded
together with my implementation from
<http://www.claas-solutions.de/cxxrt/>. Of course, I'm also interested
in problem reports for my testsuite and I'm willing to help with the
use of it.

Anyway, here are the problem reports (the copyright is just there to
provide you with the necessary right to turn the reports into test
cases of your own testsuite which would be problematic if the stuff
would be covered by the implicit copyright...):
---------------------------------------------------------------------
Copyright (C) 2000 Dietmar Kuehl, Phaidros Software AG

Permission to use, copy, modify, distribute and sell this
software for any purpose is hereby granted without fee, provided
that the above copyright notice appears in all copies and that
both that copyright notice and this permission notice appear in
supporting documentation. Dietmar Kuehl and Phaidros Software AG make
no representations about the suitability of this software for any
purpose. It is provided "as is" without express or implied warranty.
---------------------------------------------------------------------

Here are the problems I encountered while installing and testing
libstdc++-v3. For testing I used a version retrieved via "cvs update"
on 2000-07-04.

Just to arrive at an installed verison of the library, I encountered
the following problems:

- In the "configuring" section of the file
  <http://sourceware.cygnus.com/libstdc++/install.html> it is not clear
  that the configuration is to be made in the gccbuilddir. This could
  be clarified by a corresponding statement. Also, it is somewhat
  confusing that the old installation documentation is still present
  in the INSTALL file (somewhere in the gcc hiearchy) without
indication
  that this file is out of date...

- During "make bootstrap" the program "no" is not found:

    make[2]: Entering directory `/usr/src/gcc/gcc-build/gcc/po'
    file=`echo en_GB | sed 's,.*/,,'`.gmo \
      && rm -f $file && PATH=../src:$PATH no -o $file
/usr/src/gcc/gcc-source/gcc/po/en_GB.po
    /bin/sh: no: command not found

  My workaround for this was to create a script called "no" which does
  nothing and which is found in my PATH.

- The file "bits/atomicity.h" included from
  "libstdc++-v3/bits/basic_string.h" is missing. This can be due to
  a misuse of cvs, though: I just used "cvs update" in the gcc source
  directory and I'm not sure whether this will retrieve new files.
Since
  I'm currently not connected to the net, I have temporarily replaced
  the the include with the following lines:

    typedef int _Atomic_word;
    static void __atomic_add(int* _M_state, int i) { *_M_state += i; }
    static int __exchange_and_add(int* _M_state, int i) { int rc =
*_M_state; *_M_state += i; return rc; }

  Since my tests don't do multi-threading tests, this should not be
  harmful... During installation the file atomicity.h is needed again.
  I have just touch(1)ed it for this purposed...

  BTW, my first attempt was to use 'inline' functions rather than
'static'
  functions. This didn't work due to an internal compiler error:

    In file included from
/usr/src/gcc/gcc-source/libstdc++-v3/bits/locale_facets.tcc:201:
    /usr/src/gcc/gcc-source/libstdc++-v3/bits/basic_string.h: In
instantiation of `std::_Format_cache<_CharT>::_M_populate
(std::ios_base &) [with _CharT = __wchar_t]':
    /usr/src/gcc/gcc-source/libstdc++-v3/src/locale-inst.cc:78:  
instantiated from here
    /usr/src/gcc/gcc-source/libstdc++-v3/bits/basic_string.h:344:
Internal compiler error.
    /usr/src/gcc/gcc-source/libstdc++-v3/bits/basic_string.h:344:
Please submit a full bug report.

  I haven't tracked down the cause of this error...

- For the file "libstdc++-v3/bits/std_cwctype.h" lots of warnings of
  the from

    /usr/src/gcc/gcc-source/libstdc++-v3/bits/std_cwctype.h: In
function `int std::_S_iswgraph_helper
    (unsigned int)':
    /usr/src/gcc/gcc-source/libstdc++-v3/bits/std_cwctype.h:145:
warning: comparison of unsigned expression
    >= 0 is always true

  are produced (one for each wide character classification
  function). Since warnings are treated as errors, this is somewhat
  problematic. These warnings are due to the style how 'wint_t' and the
  macros are defined in "/usr/include/wctype.h". Since I don't want to
  hack my system header I have changed the functions in "std_cwctype.h"
  to cast the 'wint_t' argument to 'int'.

- I got lots of errors of the form

    /usr/src/gcc/gcc-source/libstdc++-v3/bits/std_valarray.h:738:43:
pasting would not give a valid preprocessing token

  which are apparently due to the use of 'operator##_Op' in certain
  macros. I replaced the use of 'operator##_Op' by 'operator _Op' in
  several places in several files.

This already consumed quite a lot resources in terms of diskspace, time
to track the bugs, and time to compile the stuff (I need the machine
for
other work, too, and due to the errors it was not possible to compile
the stuff in times where it was needed, at least not completely).

As a side note, I want to mention that compiling code using
libstdc++-v3
is rather slow! ... at least when comparing it with CXXRT: The other
implementations I used seem to have similar compile time
characteristics
as libstdc++-v3. Apparently nobody, expect myself, is concerned about
compile time...

Now to the errors discovered using my testsuite:

- The following program is supposed to print "OK". It does not:

    #include <locale>
    #include <iostream>

    int main(int ac, char *av[])
    {
      if (std::isspace(L' ', std::locale()))
	std::cout << "OK\n";
      else
	std::cout << "not a space!\n";
      return 0;
    }

  Apparently wide character classification is not correctly
  implemented.  This error is first detected by the test for the
  'std::basic_istream::sentry' class: The corresponding test fails
  due to this problem. Actually, this problem seems to be the
  cause of several test failures eg. whenever whitespace has to
  be skipped.

- Exception handling for the formatted input functions is not
  implemented correctly. There are two errors:
  - 'badbit' is not turned on if an exception is thrown (eg. by
    the stream buffer) but 'failbit' is turned on instead.
  - The exception is rethrown.

  This is demonstrated by the following program:

    #include <istream>
    #include <streambuf>
    #include <iostream>
    #include <stdexcept>

    class testbuf: public std::streambuf
    {
      std::streambuf::int_type underflow()
	{
	  throw std::exception();
	}
    };

    int main()
      {
	testbuf      sbuf;
	std::istream in(&sbuf);
	int val;

	try { in >> val; } catch (...) { std::cout << "oops!\n"; }

	if (in.rdstate() == std::ios_base::badbit)
	  std::cout << "OK\n";
      }

  According to 27.6.1.2.1 this program should print "OK" because
  the exception is not to be rethrown (the default settings for
  'exceptions()' is 'goodbit') and only 'badbit' is to be set. It
prints
  "oops!" instead... It can be argued that 'failbit' is to be set in
  addition to 'badbit' but I can't see where the standard says so.

  The same applies to basically all other types to be read (ie. 'int'
  was just choosen as an example) and to both narrow and wide character
  streams.

- According to the resolution to issue 118, the following program
should
  print "long" three times. On the basis of the standard it is somewhat
  questionable what the output should be but since the standard library
  is not allowed to add virtual functions to standard classes, I can't
  see any other resolution anyway.

    #include <locale>
    #include <iostream>
    #include <istream>
    #include <streambuf>
    #include <iterator>
    #include <sstream>

    class my_num_get: public std::num_get<char>
    {
      typedef std::num_get<char>::iter_type It;
      It do_get(It b, It, std::ios_base&, std::ios_base::iostate&,
long&) const
	{
	  std::cout << "long\n";
	  return b;
	}
    };

    int main()
    {
      std::locale        loc(std::locale::classic(), new my_num_get);
      std::istringstream in("1 1 1");
      in.imbue(loc);

      short s;
      int   i;
      long  l;
      in >> s >> i >> l;
    }

  On the basis of the defect reports it is absolutely clear what the
  output of this program should be... The initialization of 'in' to
  use three '1's is there to have "long" be written at least once
  with the broken implementation in libstc++...

- According to 27.6.1.2.3, forth bullet of paragraph 7, reading of
  C-strings stops if the next character is a null character
  ('charT()'). If no character is extracted, 'failbit' is set. Thus,
  the following program should print "OK":

    #include <sstream>
    #include <string>
    #include <iostream>

    int main()
    {
      char const* initstr = "\0mno";
      std::istringstream in(std::string(initstr, initstr + 4));
      char str[10];
      in >> str;
      if (in.fail())
	std::cout << "OK\n";
      else
	std::cout << "there was at least one character extracted!\n";
    }

  This program does print something else... The same problem occures
  with 'signed' and 'unsigned' C strings, too.

- The following program "hangs" for some reason. It should just copy
  the input buffer and terminate:

    #include <sstream>
    #include <istream>
    #include <streambuf>

    class unbufferedbuf: public std::streambuf
    {
    public:
      unbufferedbuf(char* s, int sz): str(s), size(sz), current(0) {}
      std::streambuf::int_type underflow()
        {
          return current < size? str[current]:
std::char_traits<char>::eof();
        }
      std::streambuf::int_type uflow()
        {
          return current < size? str[current++]:
std::char_traits<char>::eof();
        }
      std::streambuf::int_type pbackfail(std::streambuf::int_type c)
	{
	  return str[--current];
	}

      char* str;
      int size;
      int current;
    };

    int main()
    {
      char str[] = "  0123456789 abcdefghijklmnopqrstuvwxyz\000ABC";
      std::istream in(new unbufferedbuf(str, sizeof(str)));

      std::stringbuf sb;
      in >> &sb;
    }

  The same problem occures with wide characters. Apparently the problem
  is due to the stream buffer behaving as if it is unbuffered which is,
  however, legal behavior for stream buffers.

- Apparently the C library names are not declared in namespace 'std'.
  This might be due to some configuration switch which I haven't
  enabled (I only enabled libstdc++-v3 and a different installation
  directory).

OK, now have to work for the company a little bit. This should keep
people busy anyway... Here is a summary of my testsuite after running
it on the libstdc++

  # of expected passes            690
  # of unexpected failures        127
  # of expected failures          2
  # of unresolved testcases       68

There are a few (two or three) tests which are specific to my
implementation which are in my testsuite. I have found one error in my
testsuite while looking for the problem (a simple typo in the expected
output) and I have spotted one failure which is due to an illegal use
of a 'std::pair'. However, I would estimate that there are about 100
failure which are still to be analysed and which are not due to
testsuite
errors. However, some problems like the character classification cause
multiple problems.

For further reports I would appreciate it if I could get instructions
how
to install the library (and if necessary the compiler) "out of the box"
such that I can start installation when taking a [long] break. Also, I
would appreciate if the reported bugs are corrected to avoid
investigation
of test failures which are due to already reported problems.

Regards,
  Dietmar


=====
<mailto:dietmar_kuehl@yahoo.com>
<http://www.dietmar-kuehl.de/>

__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/