_GLIBCPP_HAVE_S_ISREG always undefined for cross compilers (problem with ifstream::in_avail())
Gernot Hillier
gernot.hillier@siemens.com
Fri Jan 2 13:47:00 GMT 2004
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
More information about the Libstdc++
mailing list