This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Exposing stdio_sync_filebuf<>::_M_file (was: The patch for PR libstdc++/14097)
- From: KRECKEL Richard NGLTD <Richard dot Kreckel at framatome-anp dot com>
- To: "'Benjamin Kosnik'" <bkoz at redhat dot com>
- Cc: libstdc++ at gcc dot gnu dot org
- Date: Wed, 25 Feb 2004 20:08:20 +0100
- Subject: Exposing stdio_sync_filebuf<>::_M_file (was: The patch for PR libstdc++/14097)
On Tuesday, February 24, Benjamin Kosnik wrote:
> Richard, my apologies. I'd confused this message with the
> stdio_fstream patches. This email thread is pretty discombobulated:
> perhaps you'd be better off starting a new one, with a summary of
> the issues and a current patch.
All right, here we go.
> Ok. First, please submit a patch, a ChangeLog entry, the whole deal.
> For more information, see the contributors section of the libstdc++
> documentation.
Consensus on exposing the FILE* of stdio_sync_filebuf<> seems to have been
reached here: <http://gcc.gnu.org/ml/libstdc++/2004-02/msg00189.html>.
I am just not certain which of the following two patches is the preferred
one. Both apply to GCC-3.4-20040218. The first one just adds two
necessary entries *somewhere* in config/linker-map.gnu: (Watch out the
comment there, I couldn't find a better place.)
diff -Naur gcc-3.4-20040218.orig/libstdc++-v3/ChangeLog
gcc-3.4-20040218/libstdc++-v3/ChangeLog
--- gcc-3.4-20040218.orig/libstdc++-v3/ChangeLog 2004-02-17
20:23:14.000000000 +0100
+++ gcc-3.4-20040218/libstdc++-v3/ChangeLog 2004-02-25
19:26:59.000000000 +0100
@@ -1,3 +1,9 @@
+2004-02-25 Richard B. Kreckel <Richard.Kreckel@Framatome-ANP.com>
+
+ * include/ext/stdio_sync_filebuf.h: Add member function for
+ accessing representation __gnu_cxx::stdio_sync_filebuf<>::c_file().
+ * config/linker-map.gnu: Add above function.
+
2004-02-17 Paolo Carlini <pcarlini@suse.de>
* include/bits/locale_facets.tcc (num_get<>::_M_extract_float,
diff -Naur gcc-3.4-20040218.orig/libstdc++-v3/config/linker-map.gnu
gcc-3.4-20040218/libstdc++-v3/config/linker-map.gnu
--- gcc-3.4-20040218.orig/libstdc++-v3/config/linker-map.gnu 2004-02-11
07:03:59.000000000 +0100
+++ gcc-3.4-20040218/libstdc++-v3/config/linker-map.gnu 2004-02-25
19:22:21.000000000 +0100
@@ -74,6 +74,10 @@
# Names not in an 'extern' block are mangled names.
+ # Well, this is almost certainly the wrong place for this MF:
+ # __gnu_cxx::stdio_sync_filebuf<>::c_file()
+ _ZN9__gnu_cxx18stdio_sync_filebufI[cw]St11char_traitsI[cw]EE6c_fileEv;
+
# operator new(size_t)
_Znw[jm];
# operator new(size_t, std::nothrow_t const&)
diff -Naur
gcc-3.4-20040218.orig/libstdc++-v3/include/ext/stdio_sync_filebuf.h
gcc-3.4-20040218/libstdc++-v3/include/ext/stdio_sync_filebuf.h
--- gcc-3.4-20040218.orig/libstdc++-v3/include/ext/stdio_sync_filebuf.h
2003-12-09 05:31:53.000000000 +0100
+++ gcc-3.4-20040218/libstdc++-v3/include/ext/stdio_sync_filebuf.h
2004-02-25 19:23:51.000000000 +0100
@@ -81,6 +81,17 @@
: _M_file(__f), _M_unget_buf(traits_type::eof())
{ }
+ /**
+ * @return The underlying FILE*.
+ *
+ * This function can be used to access the underlying C file
pointer.
+ * Note that there is no way for the library to track what you do
+ * with the file, so be careful.
+ */
+ FILE*
+ c_file()
+ { return this->_M_file; }
+
protected:
int_type
The other one takes advantage of the fact that inline is not inline in g++
and explicitly declares the two instanciations inline after the class
definition:
diff -Naur gcc-3.4-20040218.orig/libstdc++-v3/ChangeLog
gcc-3.4-20040218/libstdc++-v3/ChangeLog
--- gcc-3.4-20040218.orig/libstdc++-v3/ChangeLog 2004-02-17
20:23:14.000000000 +0100
+++ gcc-3.4-20040218/libstdc++-v3/ChangeLog 2004-02-25
19:35:20.000000000 +0100
@@ -1,3 +1,8 @@
+2004-02-25 Richard B. Kreckel <Richard.Kreckel@Framatome-ANP.com>
+
+ * include/ext/stdio_sync_filebuf.h: Add member function for
+ accessing representation __gnu_cxx::stdio_sync_filebuf<>::c_file().
+
2004-02-17 Paolo Carlini <pcarlini@suse.de>
* include/bits/locale_facets.tcc (num_get<>::_M_extract_float,
diff -Naur
gcc-3.4-20040218.orig/libstdc++-v3/include/ext/stdio_sync_filebuf.h
gcc-3.4-20040218/libstdc++-v3/include/ext/stdio_sync_filebuf.h
--- gcc-3.4-20040218.orig/libstdc++-v3/include/ext/stdio_sync_filebuf.h
2003-12-09 05:31:53.000000000 +0100
+++ gcc-3.4-20040218/libstdc++-v3/include/ext/stdio_sync_filebuf.h
2004-02-25 19:34:14.000000000 +0100
@@ -81,6 +81,16 @@
: _M_file(__f), _M_unget_buf(traits_type::eof())
{ }
+ /**
+ * @return The underlying FILE*.
+ *
+ * This function can be used to access the underlying C file
pointer.
+ * Note that there is no way for the library to track what you do
+ * with the file, so be careful.
+ */
+ FILE*
+ c_file();
+
protected:
int_type
@@ -198,6 +208,11 @@
};
template<>
+ inline FILE*
+ stdio_sync_filebuf<char>::c_file()
+ { return this->_M_file; }
+
+ template<>
inline stdio_sync_filebuf<char>::int_type
stdio_sync_filebuf<char>::syncgetc()
{ return std::getc(_M_file); }
@@ -231,6 +246,11 @@
#ifdef _GLIBCXX_USE_WCHAR_T
template<>
+ inline FILE*
+ stdio_sync_filebuf<wchar_t>::c_file()
+ { return this->_M_file; }
+
+ template<>
inline stdio_sync_filebuf<wchar_t>::int_type
stdio_sync_filebuf<wchar_t>::syncgetc()
{ return std::getwc(_M_file); }
Please pick one of the two approaches.
> As part of this, can you include details as to why "that does not
> seem to be enough in order to make it work inside a shared libstdc++
> on a GNU/Linux system." I don't understand what you mean. If you are
> having problems with testing, and certain tests fail, include that
> information. If you cannot get things to link, explain why. Etc, etc.
Sorry, I was under the impression that this would be something totally
obvious to you folks. What still confuses me is why this whole thing
works for the stdio_filebuf<char>::fd() member function. I can't find
any entry for it in the linker map or some other special treatment
elsewhere. It seems to just be always inlined! Why isn't this
symmetric?
Merriness
-richy.
--
Dr. Richard B. Kreckel
Framatome ANP GmbH, NGLTD
<Richard.Kreckel@Framatome-ANP.COM>
Tel: (+49)9131/189-5275, Fax: (+49)9131/189-9908