[Bug libstdc++/67015] "^[a-z0-9][a-z0-9-]*$", std::regex::extended is miscompiled

[rleigh at debian dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67015

--- Comment #2 from Roger Leigh  ---
Note regex2.cc fails with 4.9.2 but not with 4.9.3 or 5.1, so this appear to
have been fixed.

[Bug libstdc++/61059] regex throws regex_error for valid extended regular expression

[rleigh at debian dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61059

--- Comment #3 from Roger Leigh  ---
Thanks for the clarification.

Just for reference for anyone else running into this behaviour:

clang++3.3: compiles and runs
VS2012: compiles and throws regex_error
VS2013: compiles and throws regex_error

[Bug libstdc++/53631] [C++11] is unimplemented

[rleigh at debian dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53631

--- Comment #9 from Roger Leigh  ---
It would be better if  did not exist at all until functional.  If I do
regular autoconf header checks, plus a check to make sure that the needed types
can be instantiated, then these all succeed despite it being broken.  I need to
do additional tests on top of this to actually check if it's truly functional,
and then fall back to boost::regex if not.  No other standard library feature
has (IME) needed such extra checking.

Regards,
Roger

[Bug libstdc++/52719] C++11 std::regex is broken compiling simple regular expressions

[rleigh at debian dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52719

--- Comment #4 from Roger Leigh  2012-03-26 08:37:10 
UTC ---
I left the priority as "normal", but if this is generally reproducible, and not
a failure on my part, it would mean that std::regex is quite unusable in its
current form.

Thanks,
Roger

[Bug libstdc++/52719] C++11 std::regex is broken compiling simple regular expressions

[rleigh at debian dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52719

--- Comment #3 from Roger Leigh  2012-03-26 08:31:48 
UTC ---
Created attachment 26994
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26994
Machine and compiler specs

[Bug libstdc++/52719] C++11 std::regex is broken compiling simple regular expressions

[rleigh at debian dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52719

--- Comment #2 from Roger Leigh  2012-03-26 08:31:09 
UTC ---
Created attachment 26993
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26993
Preprocessed std::regex source (g++ -E)

[Bug libstdc++/52719] C++11 std::regex is broken compiling simple regular expressions

[rleigh at debian dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52719

--- Comment #1 from Roger Leigh  2012-03-26 08:29:23 
UTC ---
Created attachment 26992
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26992
Failing code using std::regex

[Bug libstdc++/52719] New: C++11 std::regex is broken compiling simple regular expressions

[rleigh at debian dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52719

 Bug #: 52719
   Summary: C++11 std::regex is broken compiling simple regular
expressions
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rle...@debian.org


Created attachment 26991
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26991
Working code using boost::regex

This is reproducible with both GCC 4.6 and 4.7.

Simple expressions such as "^[^:/,.][^:/,]*$" result in a regex_error exception
being thrown.  The exception what() method returns only "regex_error", rather
than any informative message.  The code previously used boost::regex, which
worked perfectly well.  The same regex also works with grep.

I've attached:
- working boost code
- failing std::regex code
- compiler info
- g++ -E output

The gdb backtrace is as follows:

% gdb testr
GNU gdb (GDB) 7.4-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /home/rleigh/schroot/testr...(no debugging symbols
found)...done.
(gdb) catch throw
Function "__cxa_throw" not defined.
Catchpoint 1 (throw)
(gdb) run
Starting program: /home/rleigh/schroot/testr
Catchpoint 1 (exception thrown), 0x00319f862800 in __cxa_throw ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) bt
#0  0x00319f862800 in __cxa_throw ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x00319f8b5a9d in
std::__throw_regex_error(std::regex_constants::error_type) () from
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#2  0x00408bac in std::__regex::_Compiler >::_M_bracket_expression() ()
#3  0x00407db3 in std::__regex::_Compiler >::_M_atom() ()
#4  0x00406db5 in std::__regex::_Compiler >::_M_term() ()
#5  0x00405a28 in std::__regex::_Compiler >::_M_alternative() ()
#6  0x00405a72 in std::__regex::_Compiler >::_M_alternative() ()
#7  0x00404d38 in std::__regex::_Compiler >::_M_disjunction() ()
#8  0x004042ed in std::__regex::_Compiler >::_Compiler(char const* const&, char const* const&,
std::regex_traits&, unsigned int) ()
#9  0x004037e9 in std::shared_ptr
std::__regex::__compile >(char const*
const&, char const* const&, std::regex_traits&, unsigned int) ()
#10 0x00402e89 in std::basic_regex
>::basic_regex(char const*, unsigned int) ()
#11 0x00401b16 in main ()

[Bug c++/40897] g++ error on valid syntax (call of templated object method via this pointer)

[rleigh at debian dot org]

--- Comment #7 from rleigh at debian dot org  2009-07-28 23:15 ---
Ah, so it's a defect in the actual C++ standard rather than GCC?

I was somewhat confused because while this fails:

  psess = this->chroot->get_facet();

splitting it into its component parts always succeeds:

sbuild::chroot::ptr tmp(this->chroot);
psess = tmp->template get_facet();

and I thought that they would be identical in behaviour.

But replacing this with a different pointer of the same always fails.

test_chroot_base *self(this);
psess = self->chroot->template get_facet();

(just in case this was treated specially for some reason).

Regards,
Roger


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40897

[Bug c++/40897] g++ error on valid syntax (call of templated object method via this pointer)

[rleigh at debian dot org]

--- Comment #6 from rleigh at debian dot org  2009-07-28 23:03 ---
Created an attachment (id=18264)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18264&action=view)
Preprocessed source for g++-4.5.0 (svn 149777)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40897

[Bug c++/40897] g++ error on valid syntax (call of templated object method via this pointer)

[rleigh at debian dot org]

--- Comment #4 from rleigh at debian dot org  2009-07-28 23:02 ---
Created an attachment (id=18263)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18263&action=view)
Preprocessed source for g++-4.4.1


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40897

[Bug c++/40897] g++ error on valid syntax (call of templated object method via this pointer)

[rleigh at debian dot org]

--- Comment #3 from rleigh at debian dot org  2009-07-28 23:02 ---
Created an attachment (id=18262)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18262&action=view)
Preprocessed source for g++-4.3.3


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40897

[Bug c++/40897] g++ error on valid syntax (call of templated object method via this pointer)

[rleigh at debian dot org]

--- Comment #2 from rleigh at debian dot org  2009-07-28 23:00 ---
Yes, the class for the this pointer is a template:

template 
class test_chroot_base : public TestFixture

Adding template as you suggest

  psess = this->chroot->template get_facet();

does allow the source to compile.

I'm trying to attach the preprocessed source, but bugzilla is giving me
internal errors during the upload.  I can mail them to you directly if needed.


Regards,
Roger


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40897

[Bug c++/40897] New: g++ error on valid syntax (call of templated object method via this pointer)

[rleigh at debian dot org]

duplicate directory ".."   
#include "..." search starts here:  
#include <...> search starts here:  
 .  
 .. 
 ../sbuild  
 /usr/include/uuid  
 ../bin 

/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.5.0/../../../../include/c++/4.5.0
 

/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.5.0/../../../../include/c++/4.5.0/x86_64-linux-gnu

/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.5.0/../../../../include/c++/4.5.0/backward
 /usr/local/include
 /usr/lib/gcc-snapshot/include
 /usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.5.0/include
 /usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-gnu/4.5.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-DHAVE_CONFIG_H' '-I.' '-I..'
'-I../sbuild' '-I..' '-I/usr/include/uuid' '-DTESTDATADIR="./testdata"'
'-I../bin' '-pthread' '-pedantic' '-Wall' '-Wcast-align' '-Wwrite-strings'
'-Wswitch-default' '-Wcast-qual' '-Wunused-variable' '-Wredundant-decls'
'-Wctor-dtor-privacy' '-Wnon-virtual-dtor' '-Wreorder' '-Wold-style-cast'
'-Woverloaded-virtual' '-fstrict-aliasing' '-g' '-O2' '-MT' 'sbuild-chroot.o'
'-MD' '-MP' '-MF' '.deps/sbuild-chroot.Tpo' '-c' '-o' 'sbuild-chroot.o'
'-shared-libgcc' '-mtune=generic'
 /usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/4.5.0/cc1plus
-fpreprocessed sbuild-chroot.ii -quiet -dumpbase sbuild-chroot.cc
-mtune=generic -auxbase-strip sbuild-chroot.o -g -O2 -pedantic -Wall
-Wcast-align -Wwrite-strings -Wswitch-default -Wcast-qual -Wunused-variable
-Wredundant-decls -Wctor-dtor-privacy -Wnon-virtual-dtor -Wreorder
-Wold-style-cast -Woverloaded-virtual -version -fstrict-aliasing -o
sbuild-chroot.s
GNU C++ (Debian 20090718-1) version 4.5.0 20090718 (experimental) [trunk
revision 149777] (x86_64-linux-gnu)
compiled by GNU C version 4.5.0 20090718 (experimental) [trunk revision
149777], GMP version 4.3.1, MPFR version 2.4.1-p2, MPC version 0.6
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++ (Debian 20090718-1) version 4.5.0 20090718 (experimental) [trunk
revision 149777] (x86_64-linux-gnu)
compiled by GNU C version 4.5.0 20090718 (experimental) [trunk revision
149777], GMP version 4.3.1, MPFR version 2.4.1-p2, MPC version 0.6
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: f27ed66a15ff965c437096a9bb89e09e
In file included from sbuild-chroot.cc:24:0:
test-sbuild-chroot.h: In member function 'void test_chroot_base::setUp()':
test-sbuild-chroot.h:81:65: error: expected primary-expression before '>' token
test-sbuild-chroot.h:81:67: error: expected primary-expression before ')' token

I removed all of the -f and -W options to see if this made any difference, and
it does not.


Regards,
Roger


-- 
   Summary: g++ error on valid syntax (call of templated object
method via this pointer)
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rleigh at debian dot org
 GCC build triplet: x86_64-linux-gnu
  GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40897

[Bug c++/14258] typename in a using declaration not supported

[rleigh at debian dot org]

--- Comment #10 from rleigh at debian dot org  2007-05-07 13:04 ---
Also fails with GCC 4.1.3.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14258

[Bug c++/28513] New: QOI: Diagnostic missing since 3.3.x when naming rule is violated

[rleigh at debian dot org]

class foo {
public:
  typedef int bar;
};

class baz {
public:
  foo::bar foo;
};

With G++ 3.3.6, this errors out with this diagnostic:
$ g++-3.3 -pedantic -Wall -Wcast-align -Wwrite-strings -Wswitch-default
-Wcast-qual -Wunused-variable -Wredundant-decls -Wctor-dtor-privacy
-Wnon-virtual-dtor -Wreorder -Wold-style-cast -Woverloaded-virtual
-fstrict-aliasing -c foo.cc
foo.cc:8: error: declaration of `int baz::foo'
foo.cc:1: error: changes meaning of `foo' from `class foo'

With G++ 3.4, 4.0, 4.1 and 4.2 (current CVS), no diagnostic is issued.
A diagnostic is not strictly required by the standard (§3.3.6,
basic.scope.class), but would be very useful.

Regards,
Roger


-- 
   Summary: QOI: Diagnostic missing since 3.3.x when naming rule is
violated
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
    ReportedBy: rleigh at debian dot org
 GCC build triplet: powerpc-linux-gnu
  GCC host triplet: powerpc-linux-gnu
GCC target triplet: powerpc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28513

[Bug libstdc++/28155] codecvt causes infinite loop in C locale by not returning an error status on failure

[rleigh at debian dot org]

--- Comment #2 from rleigh at debian dot org  2006-06-24 19:21 ---
Sorry, the testcase is broken.  This isn't a bug.


-- 

rleigh at debian dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28155

[Bug libstdc++/28155] codecvt causes infinite loop in C locale by not returning an error status on failure

[rleigh at debian dot org]

--- Comment #1 from rleigh at debian dot org  2006-06-24 19:16 ---
Created an attachment (id=11741)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11741&action=view)
Test codecvt roundtrip from narrow->wide->narrow.

Testcase.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28155

[Bug libstdc++/28155] New: codecvt causes infinite loop in C locale by not returning an error status on failure

[rleigh at debian dot org]

std::codecvt has in and out methods.  These are used to convert from one
codeset to another.  They return a status:

  std::codecvt_base::ok || std::codecvt_base::partial
on success or success where the conversion was only partially done

  std::codecvt_base::noconv
 if no conversion is necessary

  std::codecvt_base::error
 on error (e.g. a character could not be converted because it is an invalid
byte sequence).

When doing a conversion between char and wchar_t in UTF-8 and Latin-1 locales,
this appears to behave correctly.  But, when run in a C locale, and e.g. UTF-8
characters are in the input (invalid US-ASCII), it does not return an error, it
returns partial or ok, but the pointers to the next character are not updated,
leading to an infinite loop because the task is not completed.

A testcase is attached.  Try running in a UTF-8 locale, then run in a C locale
to compare (or comment out the first line of main).  Next, remove the UTF-8
chars from the string "foo" in main, and repeat (this works correctly in both
UTF-8 and C locales).

I think in this case codecvt is failing to correctly report an error when given
invalid input.


Regards,
Roger


-- 
   Summary: codecvt causes infinite loop in C locale by not
returning an error status on failure
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rleigh at debian dot org
 GCC build triplet: powerpc-linux-gnu
  GCC host triplet: powerpc-linux-gnu
GCC target triplet: powerpc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28155

[Bug libstdc++/28059] codecvt locale facet is broken (reproducible crash)

[rleigh at debian dot org]

--- Comment #26 from rleigh at debian dot org  2006-06-18 09:51 ---
Thiemo Seufer diagnosed this as a problem with the testcases: mbstate_t needs
explictly initialising to all-bits-zero with memset.  After doing this

  std::memset(&state, 0, sizeof(mbstate_t));

all the testcases work for me on powerpc and i386.

Since this is not a bug, it can be closed.  Sorry about that.  Perhaps the
libstdc++ doxygen documentation for codecvt could document that  
state_type/mbstate_t needs explicit initialisation before use.


Regards,
Roger


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28059

[Bug libstdc++/28059] codecvt locale facet is broken (reproducible crash)

[rleigh at debian dot org]

--- Comment #24 from rleigh at debian dot org  2006-06-18 00:27 ---
../gcc-20060613/configure --enable-languages=c,c++
--prefix=/home/rleigh/gcc-test --enable-shared --with-system-zlib
--without-included-gettext --enable-threads=posix --enable-nls
--enable-__cxa_atexit  --enable-libstdcxx-debug

$ ./wide
terminate called after throwing an instance of 'std::runtime_error'
  what():  locale::facet::_S_create_c_locale name not valid
Aborted

#0  0x0fcf77c8 in kill () at ../string/bits/string2.h:998
#1  0x0fcf754c in *__GI_raise (sig=6) at
../linuxthreads/sysdeps/unix/sysv/linux/raise.c:32
#2  0x0fcf8e68 in *__GI_abort () at ../sysdeps/generic/abort.c:88
#3  0x0ffb273c in __gnu_cxx::__verbose_terminate_handler () at
../../../../gcc-20060613/libstdc++-v3/libsupc++/vterminate.cc:98
#4  0x0ffaf87c in __cxxabiv1::__terminate (handler=0) at
../../../../gcc-20060613/libstdc++-v3/libsupc++/eh_terminate.cc:43
#5  0x0ffaf8b8 in std::terminate () at
../../../../gcc-20060613/libstdc++-v3/libsupc++/eh_terminate.cc:53
#6  0x0ffafa20 in __cxa_throw (obj=, tinfo=, dest=)
at ../../../../gcc-20060613/libstdc++-v3/libsupc++/eh_throw.cc:76
#7  0x0ff3a050 in std::__throw_runtime_error (__s=) at
../../../../gcc-20060613/libstdc++-v3/src/functexcept.cc:84
#8  0x0ffadd64 in std::locale::facet::_S_create_c_locale (__cloc=, __s=) at c++locale.cc:141
#9  0x0ff40154 in _Impl (this=0x10013080, __s=0x6 ,
__refs=)
at ../../../../gcc-20060613/libstdc++-v3/src/localename.cc:185
#10 0x0ff41ac4 in locale (this=0x7fc83950, __s=) at
../../../../gcc-20060613/libstdc++-v3/src/localename.cc:138
#11 0x100015e8 in main () at wide.cc:54

$ ./wide2
1
fffäß»
fffäß»

 ./wide3
fffäß»
1
fffäß»

Rebuilding libstdc++v3 with 'make CXXFLAGS="-O0 -g3"':

$ ./wide
terminate called after throwing an instance of 'std::runtime_error'
  what():  locale::facet::_S_create_c_locale name not valid
Aborted

(gdb) run
Starting program: /home/rleigh/wbug/wide
terminate called after throwing an instance of 'std::runtime_error'
  what():  locale::facet::_S_create_c_locale name not valid

Program received signal SIGABRT, Aborted.
0x0fcc57c8 in kill () at ../string/bits/string2.h:998
998 ../string/bits/string2.h: No such file or directory.
in ../string/bits/string2.h
Current language:  auto; currently c
(gdb) bt
#0  0x0fcc57c8 in kill () at ../string/bits/string2.h:998
#1  0x0fcc554c in *__GI_raise (sig=6) at
../linuxthreads/sysdeps/unix/sysv/linux/raise.c:32
#2  0x0fcc6e68 in *__GI_abort () at ../sysdeps/generic/abort.c:88
#3  0x0ffaf7d4 in __gnu_cxx::__verbose_terminate_handler () at
../../../../gcc-20060613/libstdc++-v3/libsupc++/vterminate.cc:98
#4  0x0ffaa238 in __cxxabiv1::__terminate (handler=0xffaf5ac
<__gnu_cxx::__verbose_terminate_handler()>)
at ../../../../gcc-20060613/libstdc++-v3/libsupc++/eh_terminate.cc:43
#5  0x0ffaa288 in std::terminate () at
../../../../gcc-20060613/libstdc++-v3/libsupc++/eh_terminate.cc:53
#6  0x0ffaa534 in __cxa_throw (obj=0x10013130, tinfo=0xffe2d58, dest=0xff1ea3c
<~runtime_error>)
at ../../../../gcc-20060613/libstdc++-v3/libsupc++/eh_throw.cc:76
#7  0x0ff120e4 in std::__throw_runtime_error (__s=0xffb7e04
"locale::facet::_S_create_c_locale name not valid")
at ../../../../gcc-20060613/libstdc++-v3/src/functexcept.cc:84
#8  0x0ffa7624 in std::locale::facet::_S_create_c_locale ([EMAIL PROTECTED],
__s=0x1001306c "en_GB.UTF8") at c++locale.cc:141
#9  0x0ff1bda4 in _Impl (this=0x10013080, __s=0x1001306c "en_GB.UTF8",
__refs=1) at ../../../../gcc-20060613/libstdc++-v3/src/localename.cc:185
#10 0x0ff1de70 in locale (this=0x7fd11950, __s=0x10002364 "") at
../../../../gcc-20060613/libstdc++-v3/src/localename.cc:138
#11 0x10001748 in main () at wide.cc:54

$ ./wide2
1
fffäß»
fffäß»

$ ./wide3
fffäß»
1
fffäß»


Regards,
Roger


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28059

[Bug libstdc++/28059] codecvt locale facet is broken (reproducible crash)

[rleigh at debian dot org]

--- Comment #23 from rleigh at debian dot org  2006-06-17 14:29 ---
This will take a few more hours.  I didn't have a built GCC tree to hand, so
I'm still waiting on "make bootstrap".


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28059

[Bug libstdc++/28059] codecvt locale facet is broken (reproducible crash)

[rleigh at debian dot org]

--- Comment #22 from rleigh at debian dot org  2006-06-16 18:19 ---
Just to summarise the current tests:

   wide   wide2  wide3
GCC ver  ppc  i386  ppc  i386  ppc  i386
  3.4OK   OKOK   OKOK   fail
  4.0fail OKOK   fail  OK   fail
  4.1fail OKOK   fail  OK   fail
  4.2fail OKOK   fail  OK   fail

GCC 3.4 is the most reliable, but I don't understand the pattern of failures.

I'll do a build in a moment as you suggest.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28059

[Bug libstdc++/28059] codecvt locale facet is broken (reproducible crash)

[rleigh at debian dot org]

--- Comment #20 from rleigh at debian dot org  2006-06-16 17:28 ---
> Before I go completely crazy, let's agree at least about a detail:
> let's not involve 3.3: in 3.3 codecvt is known to be broken and was
> completely rewritten for 3.4.

Agreed :)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28059

[Bug libstdc++/28059] codecvt locale facet is broken (reproducible crash)

[rleigh at debian dot org]

--- Comment #19 from rleigh at debian dot org  2006-06-16 17:26 ---
Created an attachment (id=11683)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11683&action=view)
C example using mbsnrtowcs

This testcase is the same as the last, but uses C only.

It looks like this:

GCC ver powerpc   i386
3.3 OKOK
3.4 OKOK
4.0 OKfail
4.1 OKfail
4.2 OKfail

The expected output is:
$ ./wide3
fffäß»
1
fffäß»

On i386 (all failing versions):
$ ./wide3
fffäß»
Segmentation fault

(gdb) run
Starting program: /home/rleigh/wide3
fffäß»

Program received signal SIGSEGV, Segmentation fault.
0xa7e0e19d in __gconv_transform_utf8_internal (step=0x805ede0,
data=0xafc2a8d0, inptrp=0xafc2aa80, inend=0x8048754 "", outbufstart=0x0,
irreversible=0xafc2a8f8, do_flush=0, consume_incomplete=1)
at ../iconv/loop.c:371
371 ../iconv/loop.c: No such file or directory.
in ../iconv/loop.c
(gdb) bt
#0  0xa7e0e19d in __gconv_transform_utf8_internal (step=0x805ede0,
data=0xafc2a8d0, inptrp=0xafc2aa80, inend=0x8048754 "", outbufstart=0x0,
irreversible=0xafc2a8f8, do_flush=0, consume_incomplete=1)
at ../iconv/loop.c:371
#1  0xa7e65bd9 in __mbsnrtowcs (dst=0xafc2a93c, src=0xafc2aa80, nmc=9,
len=162, ps=0xafc2aa84) at mbsnrtowcs.c:106
#2  0x08048503 in print_wide (str=0x804874b "fffä�237»") at wide3.c:16
#3  0x080485f0 in main () at wide3.c:40

Both the powerpc and i386 system are running the same version of glibc.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28059

[Bug libstdc++/28059] codecvt locale facet is broken (reproducible crash)

[rleigh at debian dot org]

--- Comment #17 from rleigh at debian dot org  2006-06-16 16:59 ---
Created an attachment (id=11682)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11682&action=view)
Use mbsnrtowcs directly.

This testcase is similar to the original, with the exception that it uses
mbsnrtowcs in place of the codecvt locale facet.  It also initialises the
locale with setlocale() for LC_CTYPE.

It shows some interesting results, in fact the exact opposite of the original
testcase:

GCC ver powerpc   i386
3.3 fail  fail
3.4 OKOK
4.0 OKfail
4.1 OKfail
4.2 OKfail

With this test, the expected output is this:
$ ./wide2
1
fffäß»
fffäß»

The output for the failed tests:

GCC 3.3:
powerpc (GCC 3.3 was bad at wide streams; the output is "lost"):
$ ./wide2
1
fffäß»

i386:
$ ./wide2
wide2: ../iconv/loop.c:425: utf8_internal_loop_single: Assertion `inptr -
bytebuf > (state->__count & 7)' failed.
Aborted

GCC 4.0/i386:
$ ./wide2
wide2: ../iconv/loop.c:425: utf8_internal_loop_single: Assertion `inptr -
bytebuf > (state->__count & 7)' failed.
Aborted

GCC 4.1/i386:
 ./wide2
wide2: ../iconv/loop.c:425: utf8_internal_loop_single: Assertion `inptr -
bytebuf > (state->__count & 7)' failed.
Aborted

GCC 4.2/i386:
$ ./wide2
wide2: ../iconv/loop.c:425: utf8_internal_loop_single: Assertion `inptr -
bytebuf > (state->__count & 7)' failed.
Aborted

Please do allow for the fact that one (or both) of these testcases might be
buggy; I've never used these interfaces before.  However... the behaviour is
still highly variable between the two platforms.


Regards,
Roger


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28059

[Bug libstdc++/28059] codecvt locale facet is broken (reproducible crash)

[rleigh at debian dot org]

--- Comment #15 from rleigh at debian dot org  2006-06-16 16:16 ---
$ uname -a
Linux hardknott 2.6.16.17 #7 Sun May 21 15:39:23 BST 2006 ppc GNU/Linux

$ /lib/libc.so.6
GNU C Library stable release version 2.3.6, by Roland McGrath et al.
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.0.4 20060507 (prerelease) (Debian 4.0.3-3).
Compiled on a Linux 2.6.13 system on 2006-06-08.
Available extensions:
GNU libio by Per Bothner
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
linuxthreads-0.10 by Xavier Leroy
BIND-8.2.3-T5B
libthread_db work sponsored by Alpha Processor Inc
NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
software FPU emulation by Richard Henderson, Jakub Jelinek and others


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28059

[Bug libstdc++/28059] codecvt locale facet is broken (reproducible crash)

[rleigh at debian dot org]

--- Comment #12 from rleigh at debian dot org  2006-06-16 14:39 ---
Testing on i486-linux-gnu, the results are:

3.3: fail
3.4: OK
4.0: OK
4.1: OK
4.2 snapshot: OK

So 4.0, 4.1 and 4.2 snapshot are OK on i486-linux-gnu but not on
powerpc-linux-gnu.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28059

[Bug libstdc++/28059] codecvt locale facet is broken (reproducible crash)

[rleigh at debian dot org]

--- Comment #10 from rleigh at debian dot org  2006-06-16 14:20 ---
Yes, this is all on the same Debian installation.  3.3, 3.4, 4.0, 4.1 and 4.2
(snapshot) are available.  All but 3.4 exhibit this problem.

I will test on an i686 system in a moment to check if it's powerpc-only.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28059

[Bug libstdc++/28059] codecvt locale facet is broken (reproducible crash)

[rleigh at debian dot org]

--- Comment #6 from rleigh at debian dot org  2006-06-16 13:59 ---
en_US.UTF-8 doesn't work for me either.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28059

[Bug libstdc++/28059] codecvt locale facet is broken (reproducible crash)

[rleigh at debian dot org]

--- Comment #5 from rleigh at debian dot org  2006-06-16 13:57 ---
$ g++ --version
g++ (GCC) 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)

$ g++ -o wide wide.cc
$ time ./wide
wide: ../iconv/loop.c:425: utf8_internal_loop_single: Assertion `inptr -
bytebuf > (state->__count & 7)' failed.
Aborted

real0m12.545s
user0m12.416s
sys 0m0.016s

All that run time is spent in __gconv_transform_utf8_internal, before it blows
up.

$ locale
LANG=en_GB.UTF8
LANGUAGE=en_GB:en_US:en
LC_CTYPE="en_GB.UTF8"
LC_NUMERIC="en_GB.UTF8"
LC_TIME="en_GB.UTF8"
LC_COLLATE="en_GB.UTF8"
LC_MONETARY="en_GB.UTF8"
LC_MESSAGES="en_GB.UTF8"
LC_PAPER="en_GB.UTF8"
LC_NAME="en_GB.UTF8"
LC_ADDRESS="en_GB.UTF8"
LC_TELEPHONE="en_GB.UTF8"
LC_MEASUREMENT="en_GB.UTF8"
LC_IDENTIFICATION="en_GB.UTF8"
LC_ALL=


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28059

[Bug libstdc++/28059] codecvt locale facet is broken (reproducible crash)

[rleigh at debian dot org]

--- Comment #3 from rleigh at debian dot org  2006-06-16 13:41 ---
The source is UTF-8 encoded, and it assumes you are going to run it in a UTF-8
locale.  That might possibly be why you get odd output.

The expected output should be as per the GCC 3.4 output in the original report:

$ g++-3.4 -o wide wide.cc
$ ./wide
1
fffäß»fffäß»$

where '$' is the shell prompt.  This output was also verified by someone with
access to a MS VC++ compiler (source recoded to Windows character set).

If the source file got corrupted by bugzilla, it's also available from
http://people.debian.org/~rleigh/wide.cc

I'll check out the testsuite next.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28059

[Bug libstdc++/28059] codecvt locale facet is broken (reproducible crash)

[rleigh at debian dot org]

--- Comment #1 from rleigh at debian dot org  2006-06-16 13:09 ---
Created an attachment (id=11679)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11679&action=view)
Testcase to show codecvt crash

Compile with

g++ -o wide wide.cc


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28059

[Bug libstdc++/28059] New: codecvt locale facet is broken (reproducible crash)

[rleigh at debian dot org]

The attached source file (UTF-8 encoded) demonstrates that codecvt
is broken for the simplest of transformations (UTF-8 to UCS-4).
This is pretty basic, and the underlying gconf stuff works correctly,
so the bug is either in libstdc++6 or somewhere inline in the headers.

$ ./wide
wide: ../iconv/loop.c:425: utf8_internal_loop_single: Assertion `inptr -
bytebuf > (state->__count & 7)' failed.
Aborted

While running:
(gdb) bt
#0  0x0fcc672c in __gconv_transform_utf8_internal () from /lib/tls/libc.so.6
#1  0x0fe0425c in ?? () from /lib/tls/libc.so.6
#2  0x0ffa6ef8 in std::codecvt::do_in ()
   from /usr/lib/libstdc++.so.6
#3  0x100016b4 in std::__codecvt_abstract_base::in
(this=0x100290b8, [EMAIL PROTECTED], __from=0x10013014
"[EMAIL PROTECTED]
37»",
__from_end=0x1001301d "", [EMAIL PROTECTED], __to=0x7fa405bc,
__to_end=0x7fa406fc, [EMAIL PROTECTED])
at
/usr/lib/gcc/powerpc-linux-gnu/4.1.2/../../../../include/c++/4.1.2/bits/c
odecvt.h:204
#4  0x10001244 in to_wide_string ([EMAIL PROTECTED], [EMAIL PROTECTED])
at wide.cc:22
#5  0x10001544 in main () at wide.cc:59

Program received signal SIGABRT, Aborted.
0x0fcd67bc in raise () from /lib/tls/libc.so.6
(gdb) bt
#0  0x0fcd67bc in raise () from /lib/tls/libc.so.6
#1  0x0fcd82c0 in abort () from /lib/tls/libc.so.6
#2  0x0fcce768 in __assert_fail () from /lib/tls/libc.so.6
#3  0x0fcc6c7c in __gconv_transform_utf8_internal () from /lib/tls/libc.so.6
#4  0x0fcc6c7c in __gconv_transform_utf8_internal () from /lib/tls/libc.so.6
#5  0x0fcc6c7c in __gconv_transform_utf8_internal () from /lib/tls/libc.so.6
#6  0x0fcc6c7c in __gconv_transform_utf8_internal () from /lib/tls/libc.so.6
#7  0x0fcc6c7c in __gconv_transform_utf8_internal () from /lib/tls/libc.so.6
#8  0x0fcc6c7c in __gconv_transform_utf8_internal () from /lib/tls/libc.so.6
#9  0x0fcc6c7c in __gconv_transform_utf8_internal () from /lib/tls/libc.so.6
#10 0x0fcc6c7c in __gconv_transform_utf8_internal () from /lib/tls/libc.so.6
#11 0x0fcc6c7c in __gconv_transform_utf8_internal () from /lib/tls/libc.so.6
Previous frame inner to this frame (corrupt stack?)


It affects GCC 4.2 (20060613), 4.1, 4.0, 3.3
on Debian GNU/Linux (unstable).

The program works correctly with 3.4:

$ g++-3.4 -o wide wide.cc
$ ./wide
1
fffäß»fffäß»$


Regards,
Roger


-- 
   Summary: codecvt locale facet is broken (reproducible crash)
   Product: gcc
   Version: 4.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: rleigh at debian dot org
 GCC build triplet: powerpc-linux-gnu
  GCC host triplet: powerpc-linux-gnu
GCC target triplet: powerpc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28059

[Bug libstdc++/25653] Documentation bug in ext/stdio_filebuf.h

[rleigh at debian dot org]

--- Comment #3 from rleigh at debian dot org  2006-01-03 23:49 ---
Looking at _M_cfile_created as you suggested, it does look like the
documentation is correct as it stands.

Sorry for the waste of time.


Thanks,
Roger


-- 

rleigh at debian dot org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25653

[Bug libstdc++/25653] Documentation bug in ext/stdio_filebuf.h

[rleigh at debian dot org]

--- Comment #1 from rleigh at debian dot org  2006-01-03 20:52 ---
On further investigation, it looks like when a stdio_filebuf is destroyed, this
will ultimately invoke __basic_file::close().  This calls fclose().  If
an fd is used, fdopen() is called to create a __c_file*.

If this is correct, then both file descriptors and FILE * objects will be
automatically closed, in which case this patch is needed:

--- stdio_filebuf.h.old 2006-01-03 18:49:58.653951737 +
+++ stdio_filebuf.h 2006-01-03 20:51:22.146153499 +
@@ -85,7 +85,7 @@
*Defaults to system's @c BUFSIZ.
*
*  This constructor associates a file stream buffer with an open
-   *  C @c FILE*.  The @c FILE* will not be automatically closed when the
+   *  C @c FILE*.  The @c FILE* will be automatically closed when the
*  stdio_filebuf is closed/destroyed.
   */
   stdio_filebuf(std::__c_file* __f, std::ios_base::openmode __mode,


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25653

[Bug libstdc++/25653] New: Documentation bug in ext/stdio_filebuf.h

[rleigh at debian dot org]

Using libstdc++, I've got code like this:

  __gnu_cxx::stdio_filebuf fdbuf(fd, std::ios::in);

The doxygen docs for this fd ctor say "The file descriptor will be
automatically closed when the stdio_filebuf is closed/destroyed.", but I appear
to be leaking fds due to making the assumption I was passing ownership of the
fd to this streambuf, and not closing it by hand.

Is this a documentation bug?

I've checked , and I can't see any referece to close(). 
The docs for the FILE* ctor say " The FILE* will **not** be automatically
closed when the stdio_filebuf is closed/destroyed.", so it looks like the docs
are wrong in this case.

If this is true, just adding "not" should fix it:

--- stdio_filebuf.h.old 2006-01-03 18:49:58.653951737 +
+++ stdio_filebuf.h 2006-01-03 18:50:31.536432330 +
@@ -72,7 +72,7 @@
*  @param  size  Optimal or preferred size of internal buffer, in
chars.*
*  This constructor associates a file stream buffer with an open
-   *  POSIX file descriptor. The file descriptor will be automatically
+   *  POSIX file descriptor. The file descriptor will not be automatically
*  closed when the stdio_filebuf is closed/destroyed.
   */
   stdio_filebuf(int __fd, std::ios_base::openmode __mode,


Regards,
Roger


-- 
   Summary: Documentation bug in ext/stdio_filebuf.h
   Product: gcc
   Version: 4.0.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rleigh at debian dot org
 GCC build triplet: powerpc-linux-gnu
  GCC host triplet: powerpc-linux-gnu
GCC target triplet: powerpc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25653

[Bug c++/25625] [4.0/4.1/4.2 Regression] Fails to compile C++ code when -frepo is specified.

[rleigh at debian dot org]

--- Comment #5 from rleigh at debian dot org  2006-01-02 00:06 ---
I've tested on hppa-linux-gnu and ia64-linux-gnu in addition to
powerpc-linux-gnu.  All show identical behaviour, so this doesn't look
arch-specific.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25625

[Bug c++/25625] [4.0/4.1/4.2 Regression] Fails to compile C++ code when -frepo is specified.

[rleigh at debian dot org]

--- Comment #3 from rleigh at debian dot org  2006-01-01 18:16 ---
This is the original report, in Debian Bug #345550:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=345550

This contains all the information already filed here, so this is just for the
record.


-- 

rleigh at debian dot org changed:

   What|Removed |Added

 CC||rleigh at debian dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25625

[Bug c++/25625] Fails to compile C++ code when -frepo is specified.

[rleigh at debian dot org]

--- Comment #2 from rleigh at debian dot org  2006-01-01 18:03 ---
Created an attachment (id=10574)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10574&action=view)
Preprocessed source

This is the result of running

g++ -frepo -save-temps -c test.cc


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25625

[Bug c++/25625] Fails to compile C++ code when -frepo is specified.

[rleigh at debian dot org]

--- Comment #1 from rleigh at debian dot org  2006-01-01 18:00 ---
Created an attachment (id=10573)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10573&action=view)
Testcase

This requires the Boost format library (Boost.Format).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25625

[Bug c++/25625] New: Fails to compile C++ code when -frepo is specified.

[rleigh at debian dot org]

boost/optional/optional.hpp:400:   instantiated from
‘boost::optional_detail::optional_base’
/usr/include/boost/optional/optional.hpp:407:   instantiated from
‘boost::optional’
/usr/include/boost/format/internals.hpp:56:   instantiated from here
/usr/include/boost/mpl/aux_/integral_wrapper.hpp:72: error: ‘(((unsigned
int)mpl_::integral_c::value) + 1u)’ is not a valid template
argument for type ‘unsigned int’ because it is a non-constant expression
/usr/include/boost/mpl/aux_/integral_wrapper.hpp: In instantiation of
‘mpl_::integral_c’:
/usr/include/boost/type_traits/integral_constant.hpp:21:   instantiated from
‘boost::integral_constant’
/usr/include/boost/type_traits/alignment_of.hpp:61:   instantiated from
‘boost::alignment_of’
/usr/include/boost/optional/optional.hpp:97:   instantiated from
‘boost::optional_detail::aligned_storage::dummy_u’
/usr/include/boost/optional/optional.hpp:98:   instantiated from
‘boost::optional_detail::aligned_storage’
/usr/include/boost/optional/optional.hpp:400:   instantiated from
‘boost::optional_detail::optional_base’
/usr/include/boost/optional/optional.hpp:407:   instantiated from
‘boost::optional’
/usr/include/boost/format/internals.hpp:56:   instantiated from here
/usr/include/boost/mpl/aux_/integral_wrapper.hpp:73: error: ‘(((unsigned
int)mpl_::integral_c::value) - 1u)’ is not a valid template
argument for type ‘unsigned int’ because it is a non-constant expression
/usr/include/boost/optional/optional.hpp: In instantiation of
‘boost::optional_detail::aligned_storage::dummy_u’:
/usr/include/boost/optional/optional.hpp:98:   instantiated from
‘boost::optional_detail::aligned_storage’
/usr/include/boost/optional/optional.hpp:400:   instantiated from
‘boost::optional_detail::optional_base’
/usr/include/boost/optional/optional.hpp:407:   instantiated from
‘boost::optional’
/usr/include/boost/format/internals.hpp:56:   instantiated from here
/usr/include/boost/optional/optional.hpp:97: error:
‘mpl_::integral_c::value’ is not a valid template
argument for type ‘unsigned int’ because it is a non-constant expression
/usr/include/boost/format/internals.hpp: In member function ‘void
boost::io::detail::stream_format_state::apply_on(std::basic_ios<_CharT,
_Traits>&, boost::io::detail::locale_t*) const’:
/usr/include/boost/format/internals.hpp:119: error: ‘const class
boost::optional’ has no member named ‘get’
/usr/include/boost/format/format_implementation.hpp: In member function
‘boost::io::detail::locale_t boost::basic_format::getloc()
const’:
/usr/include/boost/format/format_implementation.hpp:56: error: ‘const class
boost::optional’ has no member named ‘get’
/usr/include/boost/optional/optional.hpp: In member function ‘void
boost::optional_detail::optional_base::destroy_impl(mpl_::false_) [with T =
std::locale]’:
/usr/include/boost/optional/optional.hpp:362:   instantiated from ‘void
boost::optional_detail::optional_base::destroy() [with T = std::locale]’
/usr/include/boost/optional/optional.hpp:208:   instantiated from
‘boost::optional_detail::optional_base::~optional_base() [with T =
std::locale]’
/usr/include/boost/optional/optional.hpp:471:   instantiated from
‘boost::optional::~optional() [with T = std::locale]’
/usr/include/boost/format/format_fwd.hpp:30:   instantiated from here
/usr/include/boost/optional/optional.hpp:388: error: ‘get_ptr_impl’ was not
declared in this scope


-- 
   Summary: Fails to compile C++ code when -frepo is specified.
   Product: gcc
   Version: 4.0.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rleigh at debian dot org
 GCC build triplet: powerpc-unknown-linux-gnu
  GCC host triplet: powerpc-unknown-linux-gnu
GCC target triplet: powerpc-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25625

[Bug libstdc++/18678] Garbage output to std::wcout under some circumstances

[rleigh at debian dot org]

--- Additional Comments From rleigh at debian dot org  2004-11-29 23:50 
---
Sorry about the renaming.

Even though you aren't supposed to intermix std::cout and std::wcout, surely it
would be nicer if the undefined behaviour was the same whichever you used first?
Currently:

std::cout, std::wcout
==> wcout is garbled

std::wcout, std::cout
==> cout is silently discarded

If it would discard the invalid stream in either order, it would at least be
predictable.


Thanks,
Roger

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18678

[Bug libstdc++/18678] Garbage output to std::wcout under some circumstances

[rleigh at debian dot org]

--- Additional Comments From rleigh at debian dot org  2004-11-29 22:38 
---
I've done a little more investigation, and I've found out some more.  It's no
longer related to date formatting, so I changed the bug title.

Here's a C program to test wide character output:

#include 
#include 
#include 
#include 

int main(void)
{
  setlocale(LC_ALL, "");

  const char *narrow = "Test Unicode (narrow): ïàý Ноя!";
  fprintf(stdout, "%s\n", narrow);

  if (fwide (stderr, 1) <= 0)
fprintf(stdout, "Failed to set stderr to wide orientation\n");

  const wchar_t *wide = L"Test Unicode (wide): ïàý Ноя!";
  fwprintf(stderr, L"%ls\n", wide);

  return 0;
}


This is the output for an en_GB UTF-8 locale with GCC 3.4.4:
$ ./unicode
Test Unicode (narrow): ïàý Ноя!
Test Unicode (wide): ïàý Ноя!

Perfect.  For comparison, GCC 3.3.5:
$ ./unicode
Test Unicode (narrow): ïàý Ноя!
Test Unicode (wide): ïà ý Ноя!

Here's a C++ example:
#include 
#include 
#include 

int main(void)
{
  // Set up locale stuff...
  std::locale::global(std::locale(""));
  std::wcout.imbue(std::locale());

  std::string narrow("Test Unicode (narrow): ïàý Ноя!");
  std::cout << narrow << std::endl;

  std::wstring wide(L"Test Unicode (wide): ïàý Ноя!");
  std::wcout << wide << std::endl;

  return 0;
}

This is the output with GCC 3.4.4:
$ ./unicode 
Test Unicode (narrow): ïàý Ноя!
Test Unicode (wide): ��>O!

This is the output with GCC 3.3.5:
$ ./unicode 
Test Unicode (narrow): ïàý Ноя!
Test Unicode (wide): 

If I remove the output to std::cout, I get this:
GCC 3.4.4:
$ ./unicode 
Test Unicode (wide): ïàý Ноя!

GCC 3.3.5:
$ ./unicode 
Test Unicode (wide): 

So, GCC 3.3.5 is totally broken WRT wide output.  GCC 3.4.4 is *much* better,
but still not perfect.  The draft C standard says fwide() will not change a
stream's orientation once set, but I can seemingly output to mixed wide and
narrow streams without problems if I repeat the printf() lines in the C listing
(not that I'm complaining--I'm very pleased!).

The same does not appear to hold true for C++.  If I output to std::cout first,
all subsequent output to std::wcout is corrupted.  If I output to std::wcout
first, all subsequent output to std::cout is completely missing.  Although this
is probably going well outside the C++ spec, there seems to be no reason why I
can't do both: since both end up being output as UTF-8 anyway, at least on
GNU/Linux with UTF-8 locales, this seems a reasonable thing to do.

Regards,
Roger

-- 
   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |
Summary|std::time_put is   |Garbage output to std::wcout
   |broken with UTF-8 locales   |under some circumstances


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18678

[Bug libstdc++/18678] std::time_put is broken with UTF-8 locales

[rleigh at debian dot org]

--- Additional Comments From rleigh at debian dot org  2004-11-26 13:52 
---
Thanks for the fast response!

I guess how wchar_t output works is implementation-defined, but I'll check up on
how it should work--it's probably working entirely correctly.

Many thanks,
Roger

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18678

[Bug libstdc++/18678] std::time_put is broken with UTF-8 locales

[rleigh at debian dot org]

--- Additional Comments From rleigh at debian dot org  2004-11-26 12:13 
---
Yes, I'm using 3.4.3 (and glibc-2.3.2.ds1-18).  With respect to the comparisons,
I've now added wcsftime() to the test, and it /does/ match 
std::time_put:

$ LANG=ru_RU.UTF-8 LC_ALL=ru_RU.UTF-8 ./date3
asctime:Fri Nov 26 11:32:47 2004
strftime:   Птн 26 Ноя 2004 11:32:47
wcsftime:   B= 26 >O 2004 11:32:47
std::time_put:Птн 26 Ноя 2004 11:32:47
std::time_put: B= 26 >O 2004 11:32:47
Viewed as hexadecimal (aligned for comparison):
"Narrow" UTF-8:
П т н2  6 Н о я
==> d0 9f d1 82 d0 bd 20 32 36 20 d0 9d d0 be d1 8f
   2  0  0  4 1  1  :  3  2  :  4  7  \n
==> 20 32 30 30 34 20 31 31 3a 35 31 3a 30 34 0a

"Wide" unknown:
  B  =  2  6   >  O
==> 1f 42 3d  20 32 36 20 1d 3e 4f
   2  0  0  4 1  1  :  3  2  :  4  7  \n
==> 20 32 30 30 34 20 31 31 3a 35 31 3a 30 34 0a

However... I am using a UTF-8-capable terminal (GNOME-terminal, and the Linux
console with LatArCyrHeb font in UTF-8 mode).  In both of these cases, the
output appears as above; the "narrow" output to cout is displayed correctly (I
verified this is valid UTF-8), but the "wide" output to wcout is not valid 
UTF-8.

I expected valid UTF-8 in both cases, since this is what the locale codeset
specifies.  I'm not sure what encoding wchar_t would be using, but I assumed I
would get readable output (maybe I am wrong about that?).  It looks like the
"wide" output is a different encoding, but for some reason has not affected the
7-bit ASCII range (I would have expected something like padding with \0 if it
was outputting UCS-4).


Regards,
Roger


#include 
#include 
#include 
#include 

int main()
{
  // Set up locale stuff...
  std::locale::global(std::locale(""));
  std::cout.imbue(std::locale());
  std::wcout.imbue(std::locale());

  // Get current time
  time_t simpletime = time(0);

  // Break down time.
  std::tm brokentime;
  localtime_r(&simpletime, &brokentime);

  // Normalise.
  mktime(&brokentime);

  std::cout << "asctime:" << asctime(&brokentime);

  // Print with strftime(3)
  char buffer[40];
  std::strftime(&buffer[0], 40, "%c", &brokentime);

  std::cout << "strftime:   " << &buffer[0] << '\n';

  wchar_t wbuffer[40];
  std::wcsftime(&wbuffer[0], 40, L"%c", &brokentime);
  std::wcout << "wcsftime:   " << &wbuffer[0] << '\n';

  // Try again, but use proper locale facets...
  const std::time_put& tp =
std::use_facet >(std::cout.getloc());

  std::string pattern("std::time_put:%c\n");
  tp.put(std::cout, std::cout, std::cout.fill(),
 &brokentime, &*pattern.begin(), &*pattern.end());

  // And again, but using wchar_t...
  const std::time_put& wtp =
std::use_facet >(std::wcout.getloc());

  std::wstring wpattern(L"std::time_put: %c\n");
  wtp.put(std::wcout, std::wcout, std::wcout.fill(),
  &brokentime, &*wpattern.begin(), &*wpattern.end());


  return 0;
}



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18678