Re: [libstdc++-v3 patch] Fix invalid use of signed wchar_t and unsigned wchar_t in <type_traits>

Hi again Doug,

sorry: before committing your patch, did you fully regtest it? I'm 
asking because people are reporting regressions:

    http://gcc.gnu.org/ml/gcc-testresults/2007-07/msg00047.html

Probably, there are some trivial fallbacks, like adjusting dg-error line 
numbers in negative tests and / or removing / adjusting tests 
incorrectly involving signed / unsigned wchar_t...

Can you look into fixing that?

Paolo.

[libstdc++ patch] Committed: signed/unsigned wchar_t tweaks in testsuite

This patch fixes tweaks some line numbers in the libstdc++ test suite,
removes some uses of "unsigned wchar_t", and removes a stray
semicolon. It fixes the regressions caused by my signed/unsigned
wchar_t tweaks to libstdc++-v3.

Tested powerpc-apple-darwin8.10.0; committed to mainlne as obvious.

  - Doug

2007-07-02  Douglas Gregor  <doug.gregor <at> gmail.com>

	* testsuite/20_util/make_signed/requirements/typedefs_neg.cc:
	Tweak line numbers.
	* testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc:
	Ditto.
	* testsuite/20_util/make_unsigned/requirements/typedefs-1.cc:
	Don't try to create an unsigned wchar_t.
	* testsuite/20_util/make_unsigned/requirements/typedefs-2.cc:
	Don't try to create an unsigned wchar_t.
	* testsuite/util/testsuite_hooks.h: Remove a stray semicolon.

Index: testsuite/20_util/make_signed/requirements/typedefs_neg.cc
===================================================================
--- testsuite/20_util/make_signed/requirements/typedefs_neg.cc	(revision 126184)
+++ testsuite/20_util/make_signed/requirements/typedefs_neg.cc	(working copy)
 <at>  <at>  -49,8 +49,8  <at>  <at>  void test01()
 // { dg-error "instantiated from here" "" { target *-*-* } 41 }
 // { dg-error "instantiated from here" "" { target *-*-* } 43 }

-// { dg-error "invalid use of incomplete type" "" { target *-*-* } 497 }

Re: [libstdc++-v3 patch] Fix invalid use of signed wchar_t and unsigned wchar_t in <type_traits>

On 7/2/07, Paolo Carlini <pcarlini <at> suse.de> wrote:
> Hi again Doug,
>
> sorry: before committing your patch, did you fully regtest it? I'm
> asking because people are reporting regressions:
>
>     http://gcc.gnu.org/ml/gcc-testresults/2007-07/msg00047.html
>
> Probably, there are some trivial fallbacks, like adjusting dg-error line
> numbers in negative tests and / or removing / adjusting tests
> incorrectly involving signed / unsigned wchar_t...
>
> Can you look into fixing that?

Just committed the fix. Sorry!

  - Doug

[Patch] libstdc++/31518

Hi,

apparently, this is the way people likes best to resolve this 
enhancement request. In fact, we have already something similar in 
pool_allocator (GLIBCXX_FORCE_NEW): what can I say, makes perfect sense, 
after all. I had some minor doubts, for example about the name of the 
environment variable (I'm not uglifying it, consistently with the above 
allocator case, it's safe, doesn't appear in any header), I'll wait 
until tomorrow for better proposals...

Paolo.

/////////////

2007-07-03  Paolo Carlini  <pcarlini <at> suse.de>

	PR libstdc++/31518
	* include/debug/formatter.h (_Error_formatter::_M_get_max_length): New.
	(_Error_formatter::_Error_formatter): Use it.
	* src/debug.cc: Define.
	(_Error_formatter::_M_error): Tweak.
	* configure.ac: Adjust version to 6:10:0.
	* config/abi/pre/gnu.ver: Export _Error_formatter::_M_get_max_length
	at GLIBCXX_3.4.10.
	* testsuite/util/testsuite_abi.cc: Add GLIBCXX_3.4.10.
	* docs/html/debug.html: Document.
	* configure: Regenerate.

locale::global and wcout

GCC version: 4.1.1 20070105 (Red Hat 4.1.1-51)

I just discovered that wcout is affected when setting the global
locale using locale::global(...) - although only when the locale is
set before the first reference to wcout. In particular with respect to
the 'CTYPE' facet.

This appears to be in violation of a statement made by BS in "The C++
programming language, third edition" page 650 (mid):

"Setting the global locale does not change the behavior of existing
streams that are using the previous value of the global locale. In
particular, cin, cout, etc., are not affected. If they should be
chnaged, they must be explicitly imbued ( ) d."

So, is this an intended deviation from the standard, or am I missing something?

Strangely, I was unable to find any mention of this in the standard
(the version available via the below link.)

http://www.cantrip.org/lib-locales.html

Re: locale::global and wcout

Hi,

first, a slightly pedantic but important observation: there is only 
*one* standard in force, the ISO / IEC Standard 14882: 2003, available 
in pdf from ISO or in printed form from Wiley: anything else, in 
particular online documents or manuals / books are certainly useful 
while learning and studying the C++ language but do not represent by 
themselves a standard in any sense.

That said, in the area of locale vs streams, a lot is implementation 
defined: our implementation, by defaults has the predefined streams 
(cin, cout, wcin, wcout...) synced with stdio. That means that certainly 
the wchar_t versions are sensible to the global locale, because they use 
directly the underlying wchar_t C library functions to achieve that 
sync. You can change that behavior (thus loosing the sync) by calling 
sync_with_stdio(false) before any I / O.

Paolo.

Re: locale::global and wcout

> first, a slightly pedantic but important observation: there is only
> *one* standard in force, the ISO / IEC Standard 14882: 2003, available
> in pdf from ISO or in printed form from Wiley: anything else, in
> particular online documents or manuals / books are certainly useful
> while learning and studying the C++ language but do not represent by
> themselves a standard in any sense.
>
> That said, in the area of locale vs streams, a lot is implementation
> defined: our implementation, by defaults has the predefined streams
> (cin, cout, wcin, wcout...) synced with stdio. That means that certainly
> the wchar_t versions are sensible to the global locale, because they use
> directly the underlying wchar_t C library functions to achieve that
> sync. You can change that behavior (thus loosing the sync) by calling
> sync_with_stdio(false) before any I / O.
>
> Paolo.
>

Thanks, for pointing that about the standard out  - you are right of cource!

Your answer mostly makes sence to me, but if wcout uses the C library
functions then locale:global(...) should affect it even when wcout is
used before setting the global locale. That does not happen! Here is
the code:

wcout << 1 << endl;
locale::global(locale("en_US.UTF-8"));
wcout << L"\xF8" << endl;

It wants to output a LATIN SMALL LETTER O WITH STROKE, but instead it

Re: locale::global and wcout

Kristian Spangsege wrote:

> Do you have an explanation?

I do, but I'll keep it for me: I told you the basics, this mailing list 
is for libstdc++ development, gcc-help is much more suited for your 
problem. Anyway, I suggest putting to good use gdb, inspect a bit the 
sources (this is FREE Software, remember), and, I'm telling you a lot 
here, in case of doubts while learning locales and streams, try 
preparing an "equivalent" pure C snippet (thus using setlocale, putwc, etc.)

Paolo.

Re: locale::global and wcout

On 7/3/07, Kristian Spangsege <kristian.spangsege <at> gmail.com> wrote:
> > first, a slightly pedantic but important observation: there is only
> > *one* standard in force, the ISO / IEC Standard 14882: 2003, available
> > in pdf from ISO or in printed form from Wiley: anything else, in
> > particular online documents or manuals / books are certainly useful
> > while learning and studying the C++ language but do not represent by
> > themselves a standard in any sense.
> >
> > That said, in the area of locale vs streams, a lot is implementation
> > defined: our implementation, by defaults has the predefined streams
> > (cin, cout, wcin, wcout...) synced with stdio. That means that certainly
> > the wchar_t versions are sensible to the global locale, because they use
> > directly the underlying wchar_t C library functions to achieve that
> > sync. You can change that behavior (thus loosing the sync) by calling
> > sync_with_stdio(false) before any I / O.
> >
> > Paolo.
> >
>
> Thanks, for pointing that about the standard out  - you are right of cource!
>
> Your answer mostly makes sence to me, but if wcout uses the C library
> functions then locale:global(...) should affect it even when wcout is
> used before setting the global locale. That does not happen! Here is
> the code:
>
> wcout << 1 << endl;
> locale::global(locale("en_US.UTF-8"));
> wcout << L"\xF8" << endl;
>

Re: locale::global and wcout

> Kristian Spangsege wrote:
>
> > Do you have an explanation?
>
> I do, but I'll keep it for me: I told you the basics, this mailing list
> is for libstdc++ development, gcc-help is much more suited for your
> problem. Anyway, I suggest putting to good use gdb, inspect a bit the
> sources (this is FREE Software, remember), and, I'm telling you a lot
> here, in case of doubts while learning locales and streams, try
> preparing an "equivalent" pure C snippet (thus using setlocale, putwc, etc.)
>
> Paolo.
>

Alright, I wasn't aware that I was intruding. Have a nice day though!