two small fixes.

[Alfred Minarik]

Benjamin Kosnik wrote:
> 
> 
> can you try to come up with a small, self-contained test?
> 

First I will show a generic example, to illuminate the problem:

This fails with gcc-2.95 and gcc-2.96 if you
remove the outline definition (marked line)

struct A
{
  static const int a=5;
};

const int A::a; //the important line!

int main()
{
  const int *i = & A::a;
}

------------
This is the same with ios, and in fact could count as your requested testcase:

#include<ios>

extern "C" int printf (const char *,...);

int main(void)
{
  const std::ios_base::iostate *tst = &std::ios_base::failbit;
  printf("%x\n",(int) *tst);
}

Now there is of course the question whether one is allowed to
get the address of the static const ios_base data members
as normally you don't have a use for it (there are
other uses besides taking the address directly, but that's
what it is finally about - having it real somewhere in memory).

If you agree that this use is ok this would be conclusive enough
to integrate the patch, and all the following is unimportant. 

If not then why the linker error ?
After rethought also the libstdc++ implementation has no
other use for them beside better scoped #defin(s). And my
mentioned guess was probably wrong. Nevertheless the patch make it compile.
The mysterious part is that in the previous simple examples also gcc-2.95
fails, so there are two possibilities:

- a more complex use of those static members 
 (which in effect does not really need the address,
 or there would have been also a linker error with gcc-2.95)
- a compiler bug. (this is getting more likely) 
  
if you remove in bits/basic_ios.h line 253 (and 254).
(the original linker error points this place I assumed unimportant till now)

      _M_exception = goodbit;
      _M_streambuf = __sb;
-      iostate __state = __sb ? goodbit : badbit;
-      _M_streambuf_state = __state;
    }

after libstdc++ recompile 17_intro/header_fstream.cc passes.
so is there a use of goodbit address in that example ? well not
obvious but who knows internally 
you know those (a ? b : c ) = d uses ...
An as it is in an template, maybe the compiler keeps this possibility open,
so maybe a compiler bug...

after I replaced it with 


      _M_exception = goodbit;
      _M_streambuf = __sb;
      iostate __state;
      if (__sb) 
	__state = goodbit;
      else
	__state = badbit;
      _M_streambuf_state = __state;
    }
    
all testcases pass. But a user could easily write X ? goodbit : badbit
in his code and would be very surprised...

As there is no use of __state in init this one is simpler (and also works)

      _M_exception = goodbit;
      _M_streambuf = __sb;
      if (__sb) 
	_M_streambuf_state = goodbit;
      else
	_M_streambuf_state = badbit;
    }
    
You may integrate this, if you conclude gcc-2.96 is right in his doing,
together with deciding not to integrate my original patch.
  
ps:this is only a remark about error messages...
have you seen the linker error after this last modification
when compiling the previous simple <ios> testcase

/tmp/cc9Pa6BL.o: In function `basic_string<wchar_t, char_traits<wchar_t>, allocator<wchar_t> >::assign(basic_string<wchar_t, char_traits<wchar_t>, allocator<wchar_t> > const &)':
/home/am/gcc/egcs_current/libstdc++/bits/string.tcc:225: undefined reference to `ios_base::failbit'
collect2: ld returned 1 exit status

of course there is no failbit as fare as one can see, quite confusing
for a user, but typical, and the reason why I ignored the error place in the
original message...

ps:27_io/istream_extractors_char.cc seems to work with -O2 and gcc-2.96 


Quite some guessing, I know...
Maybe I should start trying to build a nice gcc-bugs testcase...


Alfred