--- Comment #1 from pcarlini at suse dot de 2006-04-14 17:11 ---
Gosh, this is a regression. Thanks Doug, I will apply your patch ASAP.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #4 from pcarlini at suse dot de 2006-04-14 17:38 ---
Fixed for 4.1.1.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|NEW
--- Comment #1 from pcarlini at suse dot de 2006-04-14 19:31 ---
Howard, this has been fixed in FSF 4.0.1, indeed, I cannot reproduce with
anything >= 4.0.1. Thanks, anyway.
*** This bug has been marked as a duplicate of 21286 ***
--
pcarlini at suse dot de chan
--- Comment #25 from pcarlini at suse dot de 2006-04-14 19:31 ---
*** Bug 27168 has been marked as a duplicate of this bug. ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--
pcarlini at suse dot de changed:
What|Removed |Added
Target Milestone|--- |4.1.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6702
--- Comment #5 from pcarlini at suse dot de 2006-04-17 18:35 ---
Working on a fix.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #18 from pcarlini at suse dot de 2006-04-18 17:49 ---
Probably this PR should be suspended, while waiting for the resolution of DR
456:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#456
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6257
--- Comment #2 from pcarlini at suse dot de 2006-04-19 08:59 ---
Indeed, not a libstdc++ bug. And, by the way, per the Standard (27.8.1.3/2) we
have to use fopen.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #4 from pcarlini at suse dot de 2006-04-19 10:49 ---
Working on it.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at
--- Comment #20 from pcarlini at suse dot de 2006-04-19 11:19 ---
(In reply to comment #19)
> (In reply to comment #18)
> > Probably this PR should be suspended, while waiting for the resolution of DR
> > 456:
> >
> > http://www.open-std.org/jtc1/sc22/wg
--- Comment #22 from pcarlini at suse dot de 2006-04-19 11:44 ---
(In reply to comment #21)
> I meant proposing it as a choice, with a flag like -fclean-global-namespace
> (better than a macro since it probably means changing the include path and
> redefining a few macros), wh
--- Comment #4 from pcarlini at suse dot de 2006-04-19 16:38 ---
(In reply to comment #3)
> 1.
> Agree, I wouldn't call it a bug. But I don't know where to put it other than
> here.
Maybe report it to Sun?
> 2.
> I don't think you have to use fope
--- Comment #3 from pcarlini at suse dot de 2006-04-19 18:24 ---
*** This bug has been marked as a duplicate of 16605 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #6 from pcarlini at suse dot de 2006-04-19 18:24 ---
*** Bug 27217 has been marked as a duplicate of this bug. ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--
pcarlini at suse dot de changed:
What|Removed |Added
Target Milestone|--- |4.1.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26424
--- Comment #10 from pcarlini at suse dot de 2006-04-20 09:10 ---
Well, two comments: first, I cannot reproduce with current mainline. Second,
frankly, if the implication of the issue is that in the entire implementation
of we cannot use operator, only to allow the user to write
--- Comment #11 from pcarlini at suse dot de 2006-04-20 09:25 ---
(In reply to comment #10)
Before closing this I'm only curious
to
> know why mainline is fine, maybe, simply, ADL was too zelant here? Any
> language
> lawyer ki
--- Comment #14 from pcarlini at suse dot de 2006-04-20 09:37 ---
(In reply to comment #12)
> I don't think that the problem is in the STL. The STL can be as tricky as it
> wants, including use of operator,(). It should not be possible for the actual
> operator,()s I decl
--- Comment #15 from pcarlini at suse dot de 2006-04-20 09:56 ---
We can easily get a reference to the user defined operator, from the mainline
compiler with:
template
int operator,(int i, T t) { return i; }
#include
int main()
{
std::vector v;
std::fill_n(v.begin(), 0, 1
--- Comment #18 from pcarlini at suse dot de 2006-04-20 10:20 ---
This is a self-contained example:
namespace mine1
{
struct mini_iter
{
mini_iter(int* p)
: _M_current(p) { }
int&
operator*() const
{ return *_M_current; }
mini_iter&
--- Comment #19 from pcarlini at suse dot de 2006-04-20 11:32 ---
By the way, I think I mentioned incorrectly ADL, which, in this specific case,
doesn't seem involved.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26974
--- Comment #20 from pcarlini at suse dot de 2006-04-20 11:56 ---
Everything considered, I don't think there is something to fix here, either in
the compiler (and all the other compilers I tried bahaves the same of current
g++ on Comment #18, irrespective of the position o
--- Comment #21 from pcarlini at suse dot de 2006-04-20 11:59 ---
(In reply to comment #20)
std::fill_n could be made more robust
> restricting the second template argument,
Scratch this bit, sorry.
--
http://gcc.gnu.org/bugzi
--- Comment #27 from pcarlini at suse dot de 2006-04-20 23:10 ---
(In reply to comment #23)
> Actually I don't see why the comma operator can be overridden in C++ (yes this
> I am raising a question about why the standards says it can).
Well, if we are talking about ra
--- Comment #29 from pcarlini at suse dot de 2006-04-21 10:08 ---
(In reply to comment #28)
> Wolfgang: the whitspace paper is wonderful! Actually, Bjorne explains why
> operator,() was overloadable in the Rationale.
What about this:
http://public.research.att.c
--- Comment #7 from pcarlini at suse dot de 2006-04-21 17:51 ---
Fixed for 4.1.1.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from pcarlini at suse dot de 2006-04-22 08:27 ---
(In reply to comment #2)
> I don't think this is the same bug. I can see how including would
> declare printf but why in the world would including or
> declare printf, strcpy, etc.
This is definitely
--- Comment #1 from pcarlini at suse dot de 2006-04-22 08:31 ---
(In reply to comment #0)
> /usr/bin/ld: BFD 2.14.90.0.4 20030523 internal error, aborting at
> ../../bfd/elf64-x86-64.c line 2067 in elf64_x86_64_relocate_section
>
> /usr/bin/ld: Please report this bug.
&
--- Comment #30 from pcarlini at suse dot de 2006-04-22 08:47 ---
(In reply to comment #28)
> template
> _OutputIterator
> fill_n(_OutputIterator __first, _Size __n, const _Tp& __value)
> {
> for (; __n > 0; --__n, ++__first)
[snip]
> template
> void f(W*
--- Comment #2 from pcarlini at suse dot de 2006-04-22 08:50 ---
(In reply to comment #1)
> > /usr/bin/ld: BFD 2.14.90.0.4 20030523 internal error, aborting at
> As you can see, the problem affects ld, the linker, *not* libstdc++. Please
> report it to the binutils project.
--- Comment #2 from pcarlini at suse dot de 2006-04-22 19:47 ---
Indeed, I can't reproduce with 4.1.0, 4.1.1 pre and mainline. The problem seems
still present in 4_0-branch, but frankly I have no idea which patch fixed it, I
seriously doubt was a libstdc++ patch...
--
--- Comment #3 from pcarlini at suse dot de 2006-04-22 19:54 ---
*** This bug has been marked as a duplicate of 26123 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #12 from pcarlini at suse dot de 2006-04-22 19:54 ---
*** Bug 27258 has been marked as a duplicate of this bug. ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #3 from pcarlini at suse dot de 2006-04-23 14:55 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #7 from pcarlini at suse dot de 2006-04-25 13:33 ---
Yes, we are simply implementing the resolution of DR 103: set<>::iterator is a
constant iterator type
--
pcarlini at suse dot de changed:
What|Removed
--- Comment #7 from pcarlini at suse dot de 2006-04-26 20:01 ---
I think the correct Target Milestone is 4.1.1...
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #3 from pcarlini at suse dot de 2006-04-28 20:01 ---
(In reply to comment #2)
> (In reply to comment #1)
> > Both libc and libstdc++ are considered part of the implementation which
> > means
> > both are valid to use this name space.
>
> Which
--- Comment #5 from pcarlini at suse dot de 2006-04-28 21:18 ---
(In reply to comment #4)
> Convinced of what?
Of course convinced that before renaming and re-renaming (endlessly, in
principle) we should really give some serious tought to those issues, figure
out what we are trying
--- Comment #1 from pcarlini at suse dot de 2006-05-03 00:08 ---
Hi Doug. I'm afraid that, everything considered - in particular the status of
the rope extension - we have to go with the ugly approach: things like
_Rope_iterator::_M_check() actively do change the o
--- Comment #28 from pcarlini at suse dot de 2006-05-03 17:01 ---
Fixed (again), for 4.1.1.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status
--- Comment #3 from pcarlini at suse dot de 2006-05-04 09:40 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|NEW
--- Comment #15 from pcarlini at suse dot de 2006-05-04 18:34 ---
To be honest, I dont't think this is, strictly speaking, a *bug*, because this
target is not officially supported.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7979
--- Comment #2 from pcarlini at suse dot de 2006-05-10 12:10 ---
Chris is right. Certainly we are not aware of any problem in that code, in
particular the 3.4.5 version, very close to the original HP/SGI code and very
well tested from that point of view (at least). Please provide a self
--- Comment #1 from pcarlini at suse dot de 2006-05-12 08:51 ---
This is a (new) feature, not a bug, see libstdc++/11705 and in general search
about stream orientation in the C standard (C99, 7.19.2). In a nutshell you
cannot mix byte oriented and wide oriented I/O. For now, due to the
--- Comment #1 from pcarlini at suse dot de 2006-05-12 20:12 ---
Really, there is no point in trying to implement that warning, given the
ongoing developments of the C++ standard: those overloads are already part of
the current draft of the next ("C++0x") standard (and are a
--- Comment #3 from pcarlini at suse dot de 2006-05-15 16:46 ---
Missing a self-contained, simple testcase, certainly we cannot even imagine
debugging this... Also, please use valgrind, very reliable and commonly
available.
--
pcarlini at suse dot de changed:
What
--- Comment #5 from pcarlini at suse dot de 2006-05-15 16:49 ---
Feedback not forthcoming.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status
--- Comment #5 from pcarlini at suse dot de 2006-05-15 16:58 ---
(In reply to comment #4)
> I have tried to create simple test case (about 200 rows) where I tried to
> reproduce key code fragments. In simple test case leak not reproduced. But I
> have easy reproduced it with v
--- Comment #16 from pcarlini at suse dot de 2006-05-17 10:09 ---
Ok. Hopefully, before the end of this week I can tell you something trustworthy
about binary compatibility.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196
--- Comment #3 from pcarlini at suse dot de 2006-05-18 13:46 ---
I can confirm that mainline, 4_1-branch, 4_0-branch and stock 4.0.2 are fine
together with glibc2.3.6 (-static of course).
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #21 from pcarlini at suse dot de 2006-05-21 20:28 ---
Yes, the audit trail doesn't say that in private mail with Loren we agreed that
for now we only want to minimally take into account --enable-threads, that is
exploit the __GTHREADS macro, consistently with other par
--- Comment #13 from pcarlini at suse dot de 2006-05-21 20:30 ---
No news about this one. Frankly, since x86-* would not benefit in any way, I
consider the work low priority.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24692
--- Comment #15 from pcarlini at suse dot de 2006-05-21 20:36 ---
(In reply to comment #14)
> (In reply to comment #13)
> > No news about this one. Frankly, since x86-* would not benefit in any way, I
> > consider the work low priority.
>
> What about x86_64
Of co
--- Comment #23 from pcarlini at suse dot de 2006-05-22 08:54 ---
(In reply to comment #22)
> This would mean a non-enable-threads compiled libstdc++ would skip the calls
> to __exchange_and_add?
Of course the idea would not be that of "skipping", instead provid
--- Comment #24 from pcarlini at suse dot de 2006-05-22 14:44 ---
Humm, maybe I (we ;) was wrong: I'm doing some benchmarks and it looks like the
cost of checking __gthread_active_p() compared to that of an atomic operation
is very small... More later.
--
http://gcc.gn
--- Comment #26 from pcarlini at suse dot de 2006-05-24 16:41 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from pcarlini at suse dot de 2006-05-24 20:48 ---
This triggers undefined behavior: map::operator[] inserts a default-constructed
(i.e., empty) valarray (C++03, 23.3.1.2), then valarray::operator= has
undefined behavior because the argument has 3 elements and *this zero
--- Comment #17 from pcarlini at suse dot de 2006-05-29 20:01 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from pcarlini at suse dot de 2006-06-01 21:37 ---
Gaby, I had a quick look and maybe it's just a trivial typo: the below seems
right to me and certainly fixes the testcase without regressions... What do you
think?
Thanks, Paolo.
//
Index: include
--- Comment #1 from pcarlini at suse dot de 2006-06-02 19:59 ---
Before confirming this we have to understand why we have got rather good
testresults for 4.1.1 on mips-sgi-irix6.5:
http://gcc.gnu.org/ml/gcc-testresults/2006-05/msg01513.html
Eric, any idea?
--
pcarlini at suse
--- Comment #3 from pcarlini at suse dot de 2006-06-02 20:43 ---
(In reply to comment #2)
> > Eric, any idea?
>
> I presume the message means that the functions are not declared in ?
Yes, that for sure ;) but we have got specific configure tests for that and, at
the momen
--- Comment #7 from pcarlini at suse dot de 2006-06-02 21:21 ---
(In reply to comment #4)
> Created an attachment (id=11582)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11582&action=view) [edit]
> ./mips-sgi-irix6.5/libstdc++-v3/config.log
I do not understand:
--- Comment #4 from pcarlini at suse dot de 2006-06-04 09:34 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|NEW
--- Comment #8 from pcarlini at suse dot de 2006-06-05 06:18 ---
Agreed, let's close it.
--
pcarlini at suse dot de changed:
What|Removed |Added
S
--- Comment #9 from pcarlini at suse dot de 2006-06-05 14:13 ---
To be honest, the whole situation makes no sense to me (taking also into
account that, in general, wcsftime and wcstok are not special, no C99-only, and
all the other names in the very same cwchar header are not giving
--- Comment #1 from pcarlini at suse dot de 2006-06-05 21:16 ---
This is not a bug, but standard conforming behavior (have a look to the
specific sections in 22_locale describing in detail the parsing steps and the
grammar). I'm even more sure about that because we discussed the
--- Comment #3 from pcarlini at suse dot de 2006-06-05 22:45 ---
(In reply to comment #2)
> I don't think I agree.
> 27.6.1.2.2 says:
> As in the case of the inserters, these extractors depend on the locales
> num_get<> (22.2.2.1) object to perform
> parsing
--- Comment #6 from pcarlini at suse dot de 2006-06-05 22:55 ---
(In reply to comment #5)
> Please take this up with the C++ standard since the two stages conflict.
22.2.2.1.2, p5, does not conflict, because the conversion using %g happens at
the end of Stage 2, p9, on the accumula
--- Comment #7 from pcarlini at suse dot de 2006-06-05 22:57 ---
(In reply to comment #6)
> (In reply to comment #5)
> > Please take this up with the C++ standard since the two stages conflict.
>
> 22.2.2.1.2, p5, does not conflict, because the conversion using %g happe
--- Comment #9 from pcarlini at suse dot de 2006-06-05 23:15 ---
(In reply to comment #8)
> (In reply to comment #6)
> It just seems bogus that it says %g and then goes on to do something different
> and not to take into account that strlod is allowed more than just the
>
--- Comment #11 from pcarlini at suse dot de 2006-06-06 09:36 ---
(In reply to comment #10)
> In C90 strtod does not say anything specifically about "inf", etc. However,
> it
> does say:
>
> In other than the "C" locale, additional implementation-d
--- Comment #13 from pcarlini at suse dot de 2006-06-06 22:36 ---
(In reply to comment #12)
> At this web page:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1568.htm
>
> I see this:
>
> "The formatted input functions shall support th
--- Comment #5 from pcarlini at suse dot de 2006-06-08 00:54 ---
This behavior started with this patch:
http://gcc.gnu.org/ml/libstdc++/2003-04/msg00427.html
when Pétur pointed out that, according to 27.3, p2, the standard streams are
*never* destroyed.
The ""leak"
--- Comment #11 from pcarlini at suse dot de 2006-06-09 19:42 ---
For comparison, please provide the config.log of that snapshot. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27878
--- Comment #7 from pcarlini at suse dot de 2006-06-11 17:35 ---
I have a patch in testing...
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo
--- Comment #14 from pcarlini at suse dot de 2006-06-12 22:40 ---
Ok, thanks for your feedback. Indeed, the only possible "cause" of the problem
are the finer grained checks for wchar_t vs C99 wchar_t proper functions which
are now carried out after my 2006-05-03 commit (w
--- Comment #15 from pcarlini at suse dot de 2006-06-12 23:22 ---
Not waiting anymore, but not confirmed either: we badly need an independent
confirmation.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #9 from pcarlini at suse dot de 2006-06-12 23:25 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from pcarlini at suse dot de 2006-06-16 13:30 ---
Humm, this is really puzzling because nothing non-trivial changed in that area
going from 3.4 to 4.0 and of course we all run daily the testsuite which
includes quite a few codecvt tests, which always pass smoothly. Could
--- Comment #4 from pcarlini at suse dot de 2006-06-16 13:49 ---
(In reply to comment #3)
> 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
--- Comment #7 from pcarlini at suse dot de 2006-06-16 14:09 ---
(In reply to comment #6)
> en_US.UTF-8 doesn't work for me either.
Nope, I just tried with "en_GB.utf8" too and everything works fine in that case
too. Everything considered I don't think it's
--- Comment #8 from pcarlini at suse dot de 2006-06-16 14:13 ---
(In reply to comment #5)
> All that run time is spent in __gconv_transform_utf8_internal, before it blows
> up.
Isn't that a strong hint that something is wrong with the glibc? When you say
3.4 is fine you
--- Comment #9 from pcarlini at suse dot de 2006-06-16 14:17 ---
Humm, wait, I'm working on x86-linux! Is that target specific? You can see the
issue only on powerpc?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28059
--- Comment #11 from pcarlini at suse dot de 2006-06-16 14:20 ---
(In reply to comment #9)
> Humm, wait, I'm working on x86-linux! Is that target specific? You can see the
> issue only on powerpc?
Well, in any case all the codecvt regression tests are always fine on
--- Comment #13 from pcarlini at suse dot de 2006-06-16 14:46 ---
(In reply to comment #12)
> So 4.0, 4.1 and 4.2 snapshot are OK on i486-linux-gnu but not on
> powerpc-linux-gnu.
Ok. In the meanwhile I double checked and in fact **nothing** changed in the
codecvt code going fr
--- Comment #14 from pcarlini at suse dot de 2006-06-16 15:09 ---
Can you please tell us the glibc version? I'm asking because I can reproduce on
an ia64 machine using glibc2.4, not on all the glibc2.3.6 systems I tried.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28059
--- Comment #16 from pcarlini at suse dot de 2006-06-16 16:56 ---
I can reproduce on an ia64-linux machine, so confirmed, but very puzzling on
the libstdc++-v3 side, no idea how/when we are going to deal with it...
--
pcarlini at suse dot de changed:
What|Removed
--- Comment #18 from pcarlini at suse dot de 2006-06-16 17:03 ---
Ok, thanks. 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.
--
http://gcc.gnu.or
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu
--- Comment #21 from pcarlini at suse dot de 2006-06-16 18:10 ---
Ok, I think I have something meaningful to say: seems definitely a
miscompilation. I would ask you to check on powerpc-linux what I'm seeing on
ia64-linux: the problem goes away if I both build libstdc++ and event
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bkoz at redhat dot com
|dot org
--- Comment #25 from pcarlini at suse dot de 2006-06-18 09:35 ---
(In reply to comment #24)
> terminate called after throwing an instance of 'std::runtime_error'
> what(): locale::facet::_S_create_c_locale name not valid
This is the standard throw which happens whe
--- Comment #27 from pcarlini at suse dot de 2006-06-18 10:03 ---
(In reply to comment #26)
> 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(&
--- Comment #28 from pcarlini at suse dot de 2006-06-18 10:13 ---
Correction, our testcases are already fine, zero_state does the job...
Anyway...
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #1 from pcarlini at suse dot de 2006-06-19 09:29 ---
Ok, let's see what we can do...
--
pcarlini at suse dot de changed:
What|Removed |
--- Comment #5 from pcarlini at suse dot de 2006-06-19 18:05 ---
(In reply to comment #4)
> Wow, fast reply! I hope you're successful :-) Maybe you could look at
> STLPort 5.x, AFAIK it's "more" efficient in this case. It also has
> other nice features lik
--- Comment #1 from pcarlini at suse dot de 2006-06-20 19:09 ---
Thanks Martin.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pcarlini at suse dot de
GCC host triplet: ia64-linux
http://gcc.gnu.org
--- Comment #2 from pcarlini at suse dot de 2006-06-22 16:10 ---
Basing on posts to the LWG reflector + private converstation, it seems likely
that the standard is moving to the behavior which is currently implemented by
libstdc++, relatively to badbit vs failbit. Therefore, for now I&#
1 - 100 of 2287 matches
Mail list logo
