This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [libstdc++] Don't access fpos_t.__state on uClibc w/o wchar support
- From: Bernardo Innocenti <bernie at develer dot com>
- To: Pétur Runólfsson <peturr02 at ru dot is>
- Cc: Gabriel Dos Reis <gdr at integrable-solutions dot net>, GCC Patches <gcc-patches at gcc dot gnu dot org>, libstdc++ at gcc dot gnu dot org
- Date: Wed, 24 Sep 2003 18:52:18 +0200
- Subject: Re: [libstdc++] Don't access fpos_t.__state on uClibc w/o wchar support
- Organization: Develer S.r.l.
- References: <07D05A69A3D0C14FAEA60C3ACE8E5564028F55CC@mail.ru.is>
Pétur Runólfsson wrote:
Gabriel Dos Reis wrote:
| This won't work because fpos<mbstate_t> is also used for narrow streams.
then we've get a design problem then.
This is required by the standard (char_traits<char>::pos_type is
streampos which is fpos<mbstate_t>), so there is not much that can
be done about it.
The problem with uClibc is not that mbstate_t is not present. It's
that the fpos_t structure does not contain a __state member when
the library is configured without wchar support.
We just need to disable code that needs that missing member and
perhaps return a default value instead.
Actually, the field name in uClibc is __mbstate instead of __state.
I guess C library implementations are free to name private members
whatever they like.
I also have a philosophical question: does libstdc++ need to
provide all the features mandated by the standard even when
the underlying C library doesn't support them properly?
In embedded projects, I'd rather like an incomplete libstdc++
than a needlessly fat one. I don't use locales, UTF8 or wide
streams, therefore I'd like to drop all code for dealing with
them.
--
// Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/ http://www.develer.com/
Please don't send Word attachments - http://www.gnu.org/philosophy/no-word-attachments.html