_GLIBCPP_HAVE_S_ISREG always undefined for cross compilers (problem with ifstream::in_avail())

[Gernot Hillier]

Hi!

Abstract: 

I think I found out that c++config.h always has _GLIBCPP_HAVE_S_ISREG/_IFREG 
undefined for cross compilers because configure.ac then doesn't call tests 
which need linking. Therefore the GLIBCPP_CHECK_S_ISREG_OR_S_IFREG macro is 
never called and therefore both symbols stay undefined. 

This seems to lead to a partly non-functional ifstream::in_avail() method 
(will always return 0 direct after opening a file).

------

And now the (hopefully) understandable version: ;-)

I'll tell you the whole story how I found this problem because perhaps I'm 
completely misleaded by one of my earlier conclusions. However, I'll try to 
be as short but exact as possible. If I was misleaded at some point, please 
tell (and forgive ;) ) me; I'm far from being an expert when it comes to 
libstdc++ internals - nearly everything I state here I learnt in the last few 
days...

I recently built a GNU cross compiler toolchain from the gcc-3.3 release and 
am now in the QA process for it. Therefore, I'm analyzing problems from the 
regression tests. Some days ago, I started analyzing an error in the 27_io/
istream_unformatted.cc testcase. The test aborted at the "VERIFY( i != 0 )" 
in test13(). 

I soon found out that ifstream::rdbuf()->in_avail() always returned 0 direct 
after opening a file, but seemed to work after one has done at least one call 
to the operator<<().

In include/std/std_streambuf.h:in_avail(), I saw that _M_in_cur was equal to 
_M_in_end. But as include/bits/fstream.tcc:open(...) calls 
_M_set_indeterminate() this seems to be ok for me (really?, well I assume so 
as a call to underflow() in open() which AFAICU could prevent this was 
removed in revision 1.42.2.12 of include/bits/fstream.tcc.diff).

So I understand, that the real length should be determined by include/bits/
fstream.tcc:showmanyc() which is called by in_avail() or to be more exact by 
config/io/basic_file_stdio.cc:showmanyc_helper() which is called in 
showmanyc(). Well, and showmanyc_helper() does nothing for me because neither 
FIONREAD, _GLIBCPP_HAVE_POLL nor _GLIBCPP_HAVE_S_ISREG and 
_GLIBCPP_HAVE_S_IFREG are defined.

So I seeked why these macros are undef'd in c++config.h in my build directory 
and found that configure.ac (or, configure.in as it was called in the gcc_3_3 
branch) only calls GLIBCPP_CHECK_S_ISREG_OR_S_IFREG for a native setup. For 
cross compilers, the symbols will therefore stay undef'd.

So my question is: what is the correct fix for this? Is this a known 
limitation of cross compilers? Can this problem also affect other things? A 
quick grep showed me no other methods which should be affected besides 
in_avail() (and certainly showmanyc()), but I know too less about libstdc++ 
to be sure about this...

I saw that AC_DEFINE(HAVE_S_ISREG) and AC_DEFINE(HAVE_S_IFREG) was recently 
(revision 1.14 of configure.ac) added when using newlib, but I use glibc on 
the target. So is there a nice way to do these defines for glibc too?

TIA for all helpful comments!!

-- 
Bye,

Gernot Hillier
CT SE 2
Siemens AG, Mch P