[jira] Updated: (STDCXX-424) [gcc 3.3.3] warning: inlining failed in call to std::valarray copy ctor
[
https://issues.apache.org/jira/browse/STDCXX-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Sebor updated STDCXX-424:
Severity: Compiler Warning
Fix Version/s: (was: 4.2)
4.2.1
No time to do anything about this in 4.2. Rescheduled for 4.2.1.
> [gcc 3.3.3] warning: inlining failed in call to std::valarray copy ctor
> ---
>
> Key: STDCXX-424
> URL: https://issues.apache.org/jira/browse/STDCXX-424
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 26. Numerics
>Affects Versions: 4.1.3, 4.1.4
> Environment: gcc 3.3.3 on Linux
>Reporter: Martin Sebor
>Assignee: Martin Sebor
>Priority: Minor
> Fix For: 4.2.1
>
>
> We're getting lots of warnings like the ones below from valarray tests. Even
> four levels of inlining in user code (not at all uncommon) triggers the
> noise...
> $ cat t.cpp && make t
> #include
> inline void f0 (std::valarray) { }
> inline void f1 (std::valarray va) { f0 (va); }
> inline void f2 (std::valarray va) { f1 (va); }
> inline void f3 (std::valarray va) { f2 (va); }
> inline void f4 (std::valarray va) { f3 (va); }
> int main ()
> {
> f4 (std::valarray());
> }
> gcc -c -I/amd/devco/sebor/stdcxx/include/ansi -pthread
> -I/amd/devco/sebor/stdcxx/include
> -I/build/sebor/stdcxx-gcc-3.3.3_43.41-12d/include
> -I/amd/devco/sebor/stdcxx/examples/include -pedantic -nostdinc++ -O2 -m32
> -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long
> -Wcast-align t.cpp
> gcc t.o -o t -pthread -m32 -L/build/sebor/stdcxx-gcc-3.3.3_43.41-12d/lib
> -Wl,-R/build/sebor/stdcxx-gcc-3.3.3_43.41-12d/lib -lstd12d -lsupc++ -lm
> In file included from /amd/devco/sebor/stdcxx/include/rw/_array.h:7:
> t.cpp: In function `int main()':
> /amd/devco/sebor/stdcxx/include/valarray:93: warning: inlining failed in call
>to `std::valarray<_TypeT>::valarray(const std::valarray<_TypeT>&) [with
>_TypeT = int]'
> t.cpp:6: warning: called from here
> In file included from /amd/devco/sebor/stdcxx/include/rw/_array.h:6:
> /amd/devco/sebor/stdcxx/include/valarray:93: warning: inlining failed in call
>to `std::valarray<_TypeT>::valarray(const std::valarray<_TypeT>&) [with
>_TypeT = int]'
> t.cpp:5: warning: called from here
> In file included from /amd/devco/sebor/stdcxx/include/rw/_array.h:5:
> /amd/devco/sebor/stdcxx/include/valarray:93: warning: inlining failed in call
>to `std::valarray<_TypeT>::valarray(const std::valarray<_TypeT>&) [with
>_TypeT = int]'
> t.cpp:4: warning: called from here
> In file included from /amd/devco/sebor/stdcxx/include/rw/_array.h:4:
> /amd/devco/sebor/stdcxx/include/valarray:93: warning: inlining failed in call
>to `std::valarray<_TypeT>::valarray(const std::valarray<_TypeT>&) [with
>_TypeT = int]'
> t.cpp:3: warning: called from here
> In file included from t.cpp:7,
> from t.cpp:11:
> /amd/devco/sebor/stdcxx/include/valarray:93: warning: inlining failed in call
>to `std::valarray<_TypeT>::valarray(const std::valarray<_TypeT>&) [with
>_TypeT = int]'
> t.cpp:6: warning: called from here
> In file included from t.cpp:6,
> from t.cpp:7,
> from t.cpp:11:
> /amd/devco/sebor/stdcxx/include/valarray:93: warning: inlining failed in call
>to `std::valarray<_TypeT>::valarray(const std::valarray<_TypeT>&) [with
>_TypeT = int]'
> t.cpp:5: warning: called from here
> In file included from t.cpp:5,
> from t.cpp:6,
> from t.cpp:7,
> from t.cpp:11:
> /amd/devco/sebor/stdcxx/include/valarray:93: warning: inlining failed in call
>to `std::valarray<_TypeT>::valarray(const std::valarray<_TypeT>&) [with
>_TypeT = int]'
> t.cpp:4: warning: called from here
> In file included from t.cpp:4,
> from t.cpp:5,
> from t.cpp:6,
> from t.cpp:7,
> from t.cpp:11:
> /amd/devco/sebor/stdcxx/include/valarray:93: warning: inlining failed in call
>to `std::valarray<_TypeT>::valarray(const std::valarray<_TypeT>&) [with
>_TypeT = int]'
> t.cpp:3: warning: called from here
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-182) [Sun C++ 5.7] -O -Kpic relocation error on an indexed __thread expression
[
https://issues.apache.org/jira/browse/STDCXX-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Sebor updated STDCXX-182:
Severity: Runtime Error
Affects Version/s: (was: 4.1.3)
Fix Version/s: (was: 4.2)
Removed version info since this is an External issue (i.e., one in a third
party product). Set Severity to Runtime Error (the error actually happens at
load time, i.e., strictly speaking before the program starts to run).
> [Sun C++ 5.7] -O -Kpic relocation error on an indexed __thread expression
> -
>
> Key: STDCXX-182
> URL: https://issues.apache.org/jira/browse/STDCXX-182
> Project: C++ Standard Library
> Issue Type: Bug
> Components: External
> Environment: Sun C++ 5.7
>Reporter: Martin Sebor
>
> $ cat t.cpp && CC -c -mt -O -KPIC t.cpp && CC -G -mt t.o -o libso.so
> && CC t.cpp -DMAIN -mt -L. -lso && LD_LIBRARY_PATH=. ./a.out
> int foo ();
> #ifdef MAIN
> int main () { return foo (); }
> #else
> static __thread int i [1];
> static __thread int j [2];
> int foo () { return i [j [0] + j [1]]; }
> #endif
> ld.so.1: ./a.out: fatal: relocation error: R_SPARC_JMP_SLOT:
> unidentifiable procedure reference: link-map 0xff3ef1e4, offset
> 0x3fce01, called from 0xff38054c
> Killed
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-523) data race in std::locale::classic()
[ https://issues.apache.org/jira/browse/STDCXX-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor updated STDCXX-523: Fix Version/s: (was: 4.2) 4.2.1 In 4.2.0 we don't have time to work around the Thread Checker bug that causes it to issue the diagnostic. We might want to revisit it in 4.2.1. Rescheduled. > data race in std::locale::classic() > --- > > Key: STDCXX-523 > URL: https://issues.apache.org/jira/browse/STDCXX-523 > Project: C++ Standard Library > Issue Type: Bug > Components: 22. Localization >Affects Versions: 4.1.3 >Reporter: Martin Sebor >Assignee: Martin Sebor >Priority: Minor > Fix For: 4.2.1 > > Attachments: 22.locale.statics.mt.566892.html, > 22.locale.statics.mt.html, 22.locale.statics.mt.html > > > Intel Thread Checker reports the following data race in > std::locale::classic(): > $ tcheck_cl ./22.locale.statics.mt --no-global --nthreads=2 > Intel(R) Thread Checker 3.1 command line instrumentation driver (24400) > Copyright (c) 2007 Intel Corporation. All rights reserved. > Building project > Running: > /build/sebor/stdcxx-trunk-gcc-3.4.6_3-15D/tests/22.locale.statics.mt > --no-global --nthreads=2 > # INFO (S1) (10 lines): > # TEXT: > # COMPILER: gcc 3.4.6, __VERSION__ = "3.4.6 20060404 (Red Hat 3.4.6-3)" > # ENVIRONMENT: x86_64/LP64 running linux-elf (Red Hat Enterprise Linux AS > release 4 (Nahant Update 4)) with glibc 2.3 > # FILE: 22.locale.statics.mt.cpp > # COMPILED: Aug 16 2007, 19:32:08 > # COMMENT: thread safety > > # CLAUSE: lib.locale.statics > # INFO (S1) (3 lines): > # TEXT: testing std::locale::classic() with 2 threads > # CLAUSE: lib.locale.statics > # NOTE (S2) (4 lines): > # TEXT: std::locale::global(const std::locale&) test disabled > # CLAUSE: lib.locale.statics > # LINE: 129 > # +---+--+--+--+ > # | DIAGNOSTIC| ACTIVE | TOTAL | INACTIVE | > # +---+--+--+--+ > # | (S1) INFO |2 |2 | 0% | > # | (S2) NOTE |1 |2 | 50% | > # +---+--+--+--+ > Application finished > ___ > |ID|Short De|Seve|C|Context|Description |1st Acc|2nd > Acce| > | |scriptio|rity|o|[Best] | > |ess[Bes|ss[Best]| > | |n |Name|u| | |t] | > | > | |||n| | | | > | > | |||t| | | | > | > ___ > |1 |Write ->|Erro|3|"22.loc|Memory read at > |"_mutex|"22.loca| > | |Read dat|r |6|ale.sta|"22.locale.statics.mt.cpp":78 > |.h":580|le.stati| > | |a-race || |tics.mt|conflicts with a prior memory| > |cs.mt.cp| > | ||| |.cpp":6|write at "_mutex.h":580 (flow| |p":78 > | > | ||| |9 |dependence) | | > | > ___ > |2 |Read -> |Erro|1|[libstd|Memory write at [libstd15D.so, > |"locale|[libstd1| > | |Write da|r | |15D.so,|0xb646b] conflicts with a prior |_classi|5D.so, > | > | |ta-race || |0xb6460|memory read at > |c.cpp":|0xb646b]| > | ||| |] |"locale_classic.cpp":45 (anti|45 | > | > | ||| | |dependence) | | > | > ___ > |3 |Read -> |Erro|1|[libstd|Memory write at [libstd15D.so, > |"locale|[libstd1| > | |Write da|r | |15D.so,|0xb646b] conflicts with a prior |_classi|5D.so, > | > | |ta-race || |0xb6460|memory read at > |c.cpp":|0xb646b]| > | ||| |] |"locale_classic.cpp":55 (anti|55 | > | > | ||| | |dependence) | | > | > ___ > |4 |Thread t|Info|1|Whole |Thread termination at > |"thread|"thread.| > | |erminati|rmat| |Program|"thread.cpp":84 - includes stack |.cpp":8|cpp":84 > | > | |on |ion | |1 |allocation of 10.004 MB and use |4 | > | > | ||| | |of 10.203 KB | | > | > __
[jira] Commented: (STDCXX-206) std::operator<<(ostream, string) doesn't call width(0) on ios_base::failure
[
https://issues.apache.org/jira/browse/STDCXX-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533920
]
Martin Sebor commented on STDCXX-206:
-
The originally submitted test case doesn't fail for me with gcc 3.4.6 on Linux
(I just added it to our regression test suite). Does it fail for you? If not,
do you have one showing that there is a problem?
> std::operator<<(ostream, string) doesn't call width(0) on ios_base::failure
> ---
>
> Key: STDCXX-206
> URL: https://issues.apache.org/jira/browse/STDCXX-206
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 21. Strings
>Affects Versions: 4.1.3
> Environment: all
>Reporter: Anton Pevtsov
>Assignee: Martin Sebor
>Priority: Minor
> Fix For: 4.2
>
>
> The following test fails:
> #include
> #include
> #include
> #include
> int main(int argc, char* argv[])
> {
> std::string str ("abcdefghijk");
> char buf[10];
> std::ostrstream os (buf, sizeof(buf));
> const std::streamsize width = 2;
> os.width (width);
> os.exceptions (std::ios_base::failbit | std::ios_base::badbit);
> try {
> os << str;
> }
> catch (std::ios_base::failure&) {
> }
> assert (0 == os.width ());
> return 0;
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-276) [HP aCC 3.70] ICE generating dependencies
[ https://issues.apache.org/jira/browse/STDCXX-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor updated STDCXX-276: Fix Version/s: (was: 4.2) 4.2.1 We won't have time to work around this bug in 4.2. We might want to revisit it in 4.2.1. Deferred until then. > [HP aCC 3.70] ICE generating dependencies > - > > Key: STDCXX-276 > URL: https://issues.apache.org/jira/browse/STDCXX-276 > Project: C++ Standard Library > Issue Type: Bug > Components: Build >Affects Versions: 4.1.3 > Environment: HP aCC 3.70 but not 3.63 >Reporter: Martin Sebor >Assignee: Martin Sebor >Priority: Minor > Fix For: 4.2.1 > > > HP aCC 3.70 (but not 3.63) fails with an ICE while generating dependencies > for the library sources below: > $ nice gmake -C../lib > gmake: Entering directory `/build/sebor/aCC-3.70-11d/lib' > generating dependencies for $(TOPDIR)/src/atomic.s > generating dependencies for $(TOPDIR)/src/wctype.cpp > Signal 11 > ( 0) 0x00297f64 sighandler__FiT1 + 0x134 > [/amd/packages/mdx/hpux/compilers/hp/aCC370_11.23/opt/aCC/lbin/ctcom.pa20] > ( 1) 0xc0213308 _sigreturn [/usr/lib/libc.2] > ( 2) 0x0025d900 synthesize__15LibraryRoutinesF19LibraryRoutinesEnum + 0x7c > [/amd/packages/mdx/hpux/compilers/hp/aCC370_11.23/opt/aCC/lbin/ctcom.pa20] > ( 3) 0x000c1bac enter__15LibraryRoutinesF19LibraryRoutinesEnum + 0x10 > [/amd/packages/mdx/hpux/compilers/hp/aCC370_11.23/opt/aCC/lbin/ctcom.pa20] > ( 4) 0x001864d0 > lookup__3MapF11StringTokenP11DeclarationRbQ2_3Map10LookupKindRC11DynamicListXTP4 > + 0x168 > [/amd/packages/mdx/hpux/compilers/hp/aCC370_11.23/opt/aCC/lbin/ctcom.pa20] > ( 5) 0x001865dc > find__3MapF11StringTokenP11DeclarationRbQ2_3Map10LookupKindRC11DynamicListXTP4No > + 0x9c > [/amd/packages/mdx/hpux/compilers/hp/aCC370_11.23/opt/aCC/lbin/ctcom.pa20] > ( 6) 0x0019cf38 > hasPointerToMemberComing__12PreprocessorFQ2_12Preprocessor8PTMStateP11Declaratio > + 0x844 > [/amd/packages/mdx/hpux/compilers/hp/aCC370_11.23/opt/aCC/lbin/ctcom.pa20] > ( 7) 0x002088b4 isProbablyAnIdentifier__12PreprocessorFb + 0x54 > [/amd/packages/mdx/hpux/compilers/hp/aCC370_11.23/opt/aCC/lbin/ctcom.pa20] > ( 8) 0x001883fc > resolveIdentifier__12PreprocessorFP12ScannerValue11StringToken + 0xbd4 > [/amd/packages/mdx/hpux/compilers/hp/aCC370_11.23/opt/aCC/lbin/ctcom.pa20] > ( 9) 0x001896f4 nextToken__12PreprocessorFP12ScannerValue + 0x210 > [/amd/packages/mdx/hpux/compilers/hp/aCC370_11.23/opt/aCC/lbin/ctcom.pa20] > (10) 0x000c6ea8 DoCompile__8CompilerFv + 0xd44 > [/amd/packages/mdx/hpux/compilers/hp/aCC370_11.23/opt/aCC/lbin/ctcom.pa20] > (11) 0x00280d00 DoCompile__8CompilerFP6Buffer + 0x34 > [/amd/packages/mdx/hpux/compilers/hp/aCC370_11.23/opt/aCC/lbin/ctcom.pa20] > (12) 0x002747c8 DoCompileFile__8CompilerFPc + 0x110 > [/amd/packages/mdx/hpux/compilers/hp/aCC370_11.23/opt/aCC/lbin/ctcom.pa20] > (13) 0x0026cc8c main + 0x404 > [/amd/packages/mdx/hpux/compilers/hp/aCC370_11.23/opt/aCC/lbin/ctcom.pa20] > (14) 0xc01459a8 _start + 0xc0 [/usr/lib/libc.2] > (15) 0x001989d0 $START$ + 0x178 > [/amd/packages/mdx/hpux/compilers/hp/aCC370_11.23/opt/aCC/lbin/ctcom.pa20] > Error (system problem) 689: # Compiler received signal 11 > generating dependencies for $(TOPDIR)/src/wcodecvt.cpp > Signal 11 > ... > Error (system problem) 689: # Compiler received signal 11 > generating dependencies for $(TOPDIR)/src/version.cpp > generating dependencies for $(TOPDIR)/src/vecbool.cpp > generating dependencies for $(TOPDIR)/src/valarray.cpp > generating dependencies for $(TOPDIR)/src/typeinfo.cpp > generating dependencies for $(TOPDIR)/src/tmpbuf.cpp > Signal 11 > ... > Error (system problem) 689: # Compiler received signal 11 > generating dependencies for $(TOPDIR)/src/time_put.cpp > Signal 11 > Error (system problem) 689: # Compiler received signal 11 > generating dependencies for $(TOPDIR)/src/time_get.cpp > generating dependencies for $(TOPDIR)/src/ti_wtime_put.cpp > generating dependencies for $(TOPDIR)/src/ti_wtime_get.cpp > generating dependencies for $(TOPDIR)/src/ti_wstringbuf.cpp > generating dependencies for $(TOPDIR)/src/ti_wstring.cpp > generating dependencies for $(TOPDIR)/src/ti_wstreambuf.cpp > generating dependencies for $(TOPDIR)/src/ti_wostream.cpp > generating dependencies for $(TOPDIR)/src/ti_wnumpunct.cpp > generating dependencies for $(TOPDIR)/src/ti_wnum_put.cpp > generating dependencies for $(TOPDIR)/src/ti_wnum_get.cpp > generating dependencies for $(TOPDIR)/src/ti_wmoneypunct.cpp > generating dependencies for $(TOPDIR)/src/ti_wmoney_put.cpp > generating dependencies for $(TOPDIR)/src/ti_wmoney_get.cpp > generating dependencies for $(TOPDIR)/src/ti_wmessages.cpp > generating dependencies for $(
[jira] Updated: (STDCXX-313) std::valarray::apply() uses uninitialized storage
[
https://issues.apache.org/jira/browse/STDCXX-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Sebor updated STDCXX-313:
Severity: Runtime Error
> std::valarray::apply() uses uninitialized storage
> -
>
> Key: STDCXX-313
> URL: https://issues.apache.org/jira/browse/STDCXX-313
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 26. Numerics
>Affects Versions: 4.1.2, 4.1.3
> Environment: all
>Reporter: Martin Sebor
>Assignee: Martin Sebor
> Fix For: 4.2
>
>
> The program below is designed to detect memory corruption (such as the use of
> uninitialized storage) in valarray. When compiled
> with the latest trunk it aborts at runtime.
> $ cat t.cpp && make t && ./t
> #include
> #include
> struct S {
> const S* const self;
> S (): self (this) { }
> S (const S &s): self (this) { assert (&s == s.self); }
> ~S () { assert (this == self); }
> S& operator= (const S &s) {
> assert (this == self && &s == s.self);
> return *this;
> }
> };
> S foo (S s) { return s; }
> S bar (const S &s) { return s; }
> int main ()
> {
> const std::valarray a (1);
> a.apply (foo);
> a.apply (bar);
> }
> gcc -c -I/build/sebor/dev/stdlib/include/ansi -D_RWSTDDEBUG
> -D_RWSTD_USE_CONFIG -I/build/sebor/dev/stdlib/include
> -I/build/sebor/gcc-4.1.0-11s/include
> -I/build/sebor/dev/stdlib/examples/include -pedantic -nostdinc++ -g -W
> -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long t.cpp
> gcc t.o -o t -L/build/sebor/gcc-4.1.0-11s/lib -lstd11s -lsupc++ -lm
> Assertion failed: this == self && &s == s.self, file t.cpp, line 10
> Abort (core dumped)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-313) std::valarray::apply() uses uninitialized storage
[
https://issues.apache.org/jira/browse/STDCXX-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533916
]
Martin Sebor commented on STDCXX-313:
-
As in the case of STDCXX-314, I couldn't reproduce this problem with gcc 3.4.6
or Intel C++ 10.0 on Linux, either. But I added a regression test for this
issue as well so let's keep an eye on it and if it passes on other platforms we
can go ahead and assume it either got fixed by some other change or it was a
compiler bug.
> std::valarray::apply() uses uninitialized storage
> -
>
> Key: STDCXX-313
> URL: https://issues.apache.org/jira/browse/STDCXX-313
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 26. Numerics
>Affects Versions: 4.1.2, 4.1.3
> Environment: all
>Reporter: Martin Sebor
>Assignee: Martin Sebor
> Fix For: 4.2
>
>
> The program below is designed to detect memory corruption (such as the use of
> uninitialized storage) in valarray. When compiled
> with the latest trunk it aborts at runtime.
> $ cat t.cpp && make t && ./t
> #include
> #include
> struct S {
> const S* const self;
> S (): self (this) { }
> S (const S &s): self (this) { assert (&s == s.self); }
> ~S () { assert (this == self); }
> S& operator= (const S &s) {
> assert (this == self && &s == s.self);
> return *this;
> }
> };
> S foo (S s) { return s; }
> S bar (const S &s) { return s; }
> int main ()
> {
> const std::valarray a (1);
> a.apply (foo);
> a.apply (bar);
> }
> gcc -c -I/build/sebor/dev/stdlib/include/ansi -D_RWSTDDEBUG
> -D_RWSTD_USE_CONFIG -I/build/sebor/dev/stdlib/include
> -I/build/sebor/gcc-4.1.0-11s/include
> -I/build/sebor/dev/stdlib/examples/include -pedantic -nostdinc++ -g -W
> -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long t.cpp
> gcc t.o -o t -L/build/sebor/gcc-4.1.0-11s/lib -lstd11s -lsupc++ -lm
> Assertion failed: this == self && &s == s.self, file t.cpp, line 10
> Abort (core dumped)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-314) std::valarray unary operators use uninitialized storage
[
https://issues.apache.org/jira/browse/STDCXX-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533913
]
Martin Sebor commented on STDCXX-314:
-
Which platform did you test on?
I couldn't reproduce it with gcc 3.4.6 or Intel C++ 10.0 on Linux, either. I
just added a regression test for this so let's keep an eye on it and if it
passes on other platforms we can go ahead and assume it either got fixed by
some other change or it was a compiler bug (too bad we don't have the version
of gcc it failed with...)
> std::valarray unary operators use uninitialized storage
> ---
>
> Key: STDCXX-314
> URL: https://issues.apache.org/jira/browse/STDCXX-314
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 26. Numerics
>Affects Versions: 4.1.2, 4.1.3
> Environment: all
>Reporter: Martin Sebor
>Assignee: Martin Sebor
> Fix For: 4.2
>
>
> The program below is designed to detect memory corruption (such as the use of
> uninitialized storage) in valarray. When compiled with the latest trunk it
> aborts at runtime.
> $ cat t.cpp && make t && ./t
> #include
> #include
> struct S {
> const S* const self;
> S (): self (this) { }
> S (const S &s): self (this) { assert (&s == s.self); }
> ~S () { assert (this == self); }
> S operator+ () const { assert (this == self); return *this; }
> S operator- () const { assert (this == self); return *this; }
> S operator~ () const { assert (this == self); return *this; }
> bool operator! () const { assert (this == self); return false; }
> void operator= (const S &s) { assert (this == self && &s == s.self); }
> };
> int main ()
> {
> const std::valarray a (2);
> +a;
> -a;
> ~a;
> !a;
> }
> gcc -c -I/build/sebor/dev/stdlib/include/ansi -D_RWSTDDEBUG
> -D_RWSTD_USE_CONFIG -I/build/sebor/dev/stdlib/include
> -I/build/sebor/gcc-4.1.0-11s/include
> -I/build/sebor/dev/stdlib/examples/include -pedantic -nostdinc++ -g -W
> -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long t.cpp
> gcc t.o -o t -L/build/sebor/gcc-4.1.0-11s/lib -lstd11s -lsupc++ -lm
> Assertion failed: this == self && &s == s.self, file t.cpp, line 15
> Abort (core dumped)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-314) std::valarray unary operators use uninitialized storage
[
https://issues.apache.org/jira/browse/STDCXX-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Sebor updated STDCXX-314:
Severity: Runtime Error
> std::valarray unary operators use uninitialized storage
> ---
>
> Key: STDCXX-314
> URL: https://issues.apache.org/jira/browse/STDCXX-314
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 26. Numerics
>Affects Versions: 4.1.2, 4.1.3
> Environment: all
>Reporter: Martin Sebor
>Assignee: Martin Sebor
> Fix For: 4.2
>
>
> The program below is designed to detect memory corruption (such as the use of
> uninitialized storage) in valarray. When compiled with the latest trunk it
> aborts at runtime.
> $ cat t.cpp && make t && ./t
> #include
> #include
> struct S {
> const S* const self;
> S (): self (this) { }
> S (const S &s): self (this) { assert (&s == s.self); }
> ~S () { assert (this == self); }
> S operator+ () const { assert (this == self); return *this; }
> S operator- () const { assert (this == self); return *this; }
> S operator~ () const { assert (this == self); return *this; }
> bool operator! () const { assert (this == self); return false; }
> void operator= (const S &s) { assert (this == self && &s == s.self); }
> };
> int main ()
> {
> const std::valarray a (2);
> +a;
> -a;
> ~a;
> !a;
> }
> gcc -c -I/build/sebor/dev/stdlib/include/ansi -D_RWSTDDEBUG
> -D_RWSTD_USE_CONFIG -I/build/sebor/dev/stdlib/include
> -I/build/sebor/gcc-4.1.0-11s/include
> -I/build/sebor/dev/stdlib/examples/include -pedantic -nostdinc++ -g -W
> -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long t.cpp
> gcc t.o -o t -L/build/sebor/gcc-4.1.0-11s/lib -lstd11s -lsupc++ -lm
> Assertion failed: this == self && &s == s.self, file t.cpp, line 15
> Abort (core dumped)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-584) purify reports memory leak from __rw_vfmtwhat in 18.exception test
[ https://issues.apache.org/jira/browse/STDCXX-584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Travis Vitek updated STDCXX-584: Attachment: stdcxx-584.patch Just in case it isn't clear, the test sets the function that is invoked when the library wants to throw an exception. The function that the test sets doesn't properly deallocate the exception string. There is a comment in there that indicates that the string is not supposed to be deallocated, but I think that comment is out of date wrt the code as it is now. 2007-10-10 Travis Vitek <[EMAIL PROTECTED]> STDCXX-584 * 18.exception.cpp (test_throw_proc): Deallocate exception description string passed to user throw proc to avoid memory leak. > purify reports memory leak from __rw_vfmtwhat in 18.exception test > -- > > Key: STDCXX-584 > URL: https://issues.apache.org/jira/browse/STDCXX-584 > Project: C++ Standard Library > Issue Type: Improvement > Components: Tests >Reporter: Travis Vitek >Assignee: Travis Vitek >Priority: Trivial > Fix For: 4.2.1 > > Attachments: stdcxx-584.patch > > > The library uses a system of functions for platforms that don't support > exceptions. The __rw_throw function calls __rw_vfmtwhat() to get a string > describing the exception that has occured. Under some conditions the string > is allocated from the heap as an array of characters. Eventually __rw_throw > invokes a function via pointer (__rw_throw_proc) that is supposed to process > the exception (possibly by throwing a real exception object). Unfortunately > the test does not deallocate the string that was allocated by __rw_vfmtwhat(). > Purify: Searching for all memory leaks... > Memory leaked: 3072 bytes (25.6%); potentially leaked: 0 bytes (0%) > wLK: 3072 bytes leaked in 12 blocks > * This memory was allocated from: > malloc [rtlib.o] > operator new(unsigned) [libstd15d.so] > operator new [](unsigned) [libstd15d.so] > __rw::__rw_vfmtwhat(char*, unsigned, char const*, char*) > [exception.cpp:479] > __rw::__rw_throw(int, ...) [exception.cpp:825] > test_rw_throw() [18.exception.cpp:527] > * Block of 256 bytes (12 times); last block at 0x8118de0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (STDCXX-584) purify reports memory leak from __rw_vfmtwhat in 18.exception test
purify reports memory leak from __rw_vfmtwhat in 18.exception test -- Key: STDCXX-584 URL: https://issues.apache.org/jira/browse/STDCXX-584 Project: C++ Standard Library Issue Type: Improvement Components: Tests Reporter: Travis Vitek Assignee: Travis Vitek Priority: Trivial Fix For: 4.2.1 The library uses a system of functions for platforms that don't support exceptions. The __rw_throw function calls __rw_vfmtwhat() to get a string describing the exception that has occured. Under some conditions the string is allocated from the heap as an array of characters. Eventually __rw_throw invokes a function via pointer (__rw_throw_proc) that is supposed to process the exception (possibly by throwing a real exception object). Unfortunately the test does not deallocate the string that was allocated by __rw_vfmtwhat(). Purify: Searching for all memory leaks... Memory leaked: 3072 bytes (25.6%); potentially leaked: 0 bytes (0%) wLK: 3072 bytes leaked in 12 blocks * This memory was allocated from: malloc [rtlib.o] operator new(unsigned) [libstd15d.so] operator new [](unsigned) [libstd15d.so] __rw::__rw_vfmtwhat(char*, unsigned, char const*, char*) [exception.cpp:479] __rw::__rw_throw(int, ...) [exception.cpp:825] test_rw_throw() [18.exception.cpp:527] * Block of 256 bytes (12 times); last block at 0x8118de0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-512) std::valarray computed assignment operators don't compile with a user-defined class
[
https://issues.apache.org/jira/browse/STDCXX-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Sebor updated STDCXX-512:
Severity: Compiler Error
Priority: Minor (was: Major)
Affects Version/s: 4.1.2
4.1.4
Fix Version/s: (was: 4.2)
4.2.1
It's unusual to instantiate std::valarray on a user-defined type, so setting
Priority to Minor. Since the template hasn't changed added other 4.1.x versions
to the list of Affected Versions. It's too late to fix this now so deferred for
4.2.1 (provided a compatible fix is possible).
> std::valarray computed assignment operators don't compile with a user-defined
> class
> ---
>
> Key: STDCXX-512
> URL: https://issues.apache.org/jira/browse/STDCXX-512
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 26. Numerics
>Affects Versions: 4.1.2, 4.1.3, 4.1.4
>Reporter: Martin Sebor
>Assignee: Martin Sebor
>Priority: Minor
> Fix For: 4.2.1
>
>
> The program below fails to compile because the valarray computed assignment
> operators make use of operator@ (T, T) instead of the corresponding computed
> assignment operators defined by T (i.e., T::operator@(T)).
> $ cat u.cpp && make u
> #include
> struct Value {
> Value& operator*= (const Value&) { return *this; }
> Value& operator/= (const Value&) { return *this; }
> Value& operator+= (const Value&) { return *this; }
> Value& operator-= (const Value&) { return *this; }
> Value& operator%= (const Value&) { return *this; }
> Value& operator^= (const Value&) { return *this; }
> Value& operator&= (const Value&) { return *this; }
> Value& operator|= (const Value&) { return *this; }
> Value& operator<<= (const Value&) { return *this; }
> Value& operator>>= (const Value&) { return *this; }
> };
> int main ()
> {
> std::valarray val;
> val *= val;
> val /= val;
> val += val;
> val -= val;
> val %= val;
> val ^= val;
> val &= val;
> val |= val;
> val <<= val;
> val >>= val;
> }
> gcc -c -I/amd/devco/sebor/stdcxx-4.1.3/include/ansi -D_RWSTDDEBUG -pthread
> -D_RWSTD_USE_CONFIG -I/build/sebor/stdcxx-4.1.3-gcc-3.4.3_6-15D/include
> -I/amd/devco/sebor/stdcxx-4.1.3/include
> -I/amd/devco/sebor/stdcxx-4.1.3/examples/include -pedantic -nostdinc++ -g
> -m64 -Wall -W -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long
> -Wcast-align u.cpp
> /amd/devco/sebor/stdcxx-4.1.3/include/functional: In member function
> `typename std::binary_function<_TypeT, _TypeT, _TypeT>::result_type
> std::multiplies<_TypeT>::operator()(const typename
> std::binary_function<_TypeT, _TypeT, _TypeT>::first_argument_type&, const
> typename std::binary_function<_TypeT, _TypeT, _TypeT>::second_argument_type&)
> const [with _TypeT = Value]':
> /amd/devco/sebor/stdcxx-4.1.3/include/algorithm:353: instantiated from
> `_OutputIter std::transform(_InputIter1, _InputIter1, _InputIter2,
> _OutputIter, _BinaryOperation) [with _InputIter1 = Value*, _InputIter2 =
> const Value*, _OutputIter = Value*, _BinaryOperation =
> std::multiplies]'
> /amd/devco/sebor/stdcxx-4.1.3/include/valarray:363: instantiated from
> `std::valarray<_TypeT>& std::valarray<_TypeT>::operator*=(const
> std::valarray<_TypeT>&) [with _TypeT = Value]'
> u.cpp:20: instantiated from here
> /amd/devco/sebor/stdcxx-4.1.3/include/functional:83: error: no match for
> 'operator*' in '__x * __y'
> /amd/devco/sebor/stdcxx-4.1.3/include/functional: In member function
> `typename std::binary_function<_TypeT, _TypeT, _TypeT>::result_type
> std::divides<_TypeT>::operator()(const typename std::binary_function<_TypeT,
> _TypeT, _TypeT>::first_argument_type&, const typename
> std::binary_function<_TypeT, _TypeT, _TypeT>::second_argument_type&) const
> [with _TypeT = Value]':
> /amd/devco/sebor/stdcxx-4.1.3/include/algorithm:353: instantiated from
> `_OutputIter std::transform(_InputIter1, _InputIter1, _InputIter2,
> _OutputIter, _BinaryOperation) [with _InputIter1 = Value*, _InputIter2 =
> const Value*, _OutputIter = Value*, _BinaryOperation = std::divides]'
> /amd/devco/sebor/stdcxx-4.1.3/include/valarray:376: instantiated from
> `std::valarray<_TypeT>& std::valarray<_TypeT>::operator/=(const
> std::valarray<_TypeT>&) [with _TypeT = Value]'
> u.cpp:21: instantiated from here
> /amd/devco/sebor/stdcxx-4.1.3/include/functional:96: error: no match for
> 'operator/' in '__x / __y'
> /amd/devco/sebor/stdcxx-4.1.3/include/functional: In member function
> `typename std::binary_function<_TypeT, _TypeT, _TypeT>::result_type
> std::plus<_TypeT>::operator()(const typename std::binary_function<_TypeT,
> _TypeT, _TypeT>::first_argument_t
[jira] Closed: (STDCXX-318) SIGFPE in std::valarray::cshift() on empty array
[
https://issues.apache.org/jira/browse/STDCXX-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Sebor closed STDCXX-318.
---
Resolution: Fixed
Test passes. Closing.
> SIGFPE in std::valarray::cshift() on empty array
>
>
> Key: STDCXX-318
> URL: https://issues.apache.org/jira/browse/STDCXX-318
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 26. Numerics
>Affects Versions: 4.1.2, 4.1.3
> Environment: all
>Reporter: Martin Sebor
>Assignee: Martin Sebor
> Fix For: 4.2
>
>
> The program below abends with SIGFPE due to division by zero:
> $ cat t.cpp && nice gmake t && ./t
> #include
> #include
> int main ()
> {
> const std::valarray a;
> a.cshift (1);
> }
> aCC -c -I/nfs/devco/sebor/dev/stdlib/include/ansi -I/usr/include
> -D_RWSTDDEBUG -mt -D_RWSTD_USE_CONFIG -I/nfs/devco/sebor/dev/stdlib/include
> -I/build/sebor/aCC-3.70-15S/include
> -I/nfs/devco/sebor/dev/stdlib/examples/include -Aa +nostl -g +d +DD64 +w
> +W392 +W655 +W684 +W818 +W819 +W849 t.cpp
> aCC t.o -o t -Aa +nostl -Wl,+s -Wl,+vnocompatwarnings -mt +DD64
> -L/build/sebor/aCC-3.70-15S/lib -lstd15S -lm
> Floating point exception (core dumped)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (STDCXX-309) std::valarray::operator[](std::gslice) bad result
[
https://issues.apache.org/jira/browse/STDCXX-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Sebor closed STDCXX-309.
---
Resolution: Fixed
Regression test passes in nightly builds. Closing.
> std::valarray::operator[](std::gslice) bad result
> -
>
> Key: STDCXX-309
> URL: https://issues.apache.org/jira/browse/STDCXX-309
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 26. Numerics
>Affects Versions: 4.1.2, 4.1.3
> Environment: all
>Reporter: Martin Sebor
>Assignee: Martin Sebor
> Fix For: 4.2
>
>
> The program below aborts at runtime with the latest trunk:
> $ cat t.cpp && nice gmake t && ./t
> #include
> #include
> #include
> int main ()
> {
> const int a[] = { 1, 2, 3, 4, 5, 6 };
> const std::valarray v (a, sizeof a / sizeof *a);
> const std::size_t start = 5;
> std::valarray length (1, 1);
> std::valarray stride (1, 1);
> const std::gslice gsl (start, length, stride);
> const std::valarray vsl = v [gsl];
> assert (a [start] == vsl [0]);
> }
> aCC -c -I/nfs/devco/sebor/dev/stdlib/include/ansi -I/usr/include
> -D_RWSTDDEBUG -mt -D_RWSTD_USE_CONFIG -I/nfs/devco/sebor/dev/stdlib/include
> -I/build/sebor/aCC-3.70-15S/include
> -I/nfs/devco/sebor/dev/stdlib/examples/include -Aa +nostl -g +d +DD64 +w
> +W392 +W655 +W684 +W818 +W819 +W849 t.cpp
> aCC t.o -o t -Aa +nostl -Wl,+s -Wl,+vnocompatwarnings -mt +DD64
> -L/build/sebor/aCC-3.70-15S/lib -lstd15S -lm
> Assertion failed: a [start] == vsl [0], file t.cpp, line 19
> ABORT instruction (core dumped)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-309) std::valarray::operator[](std::gslice) bad result
[
https://issues.apache.org/jira/browse/STDCXX-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533852
]
Martin Sebor commented on STDCXX-309:
-
Regression test added here:
http://svn.apache.org/viewvc?view=rev&revision=579027
> std::valarray::operator[](std::gslice) bad result
> -
>
> Key: STDCXX-309
> URL: https://issues.apache.org/jira/browse/STDCXX-309
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 26. Numerics
>Affects Versions: 4.1.2, 4.1.3
> Environment: all
>Reporter: Martin Sebor
>Assignee: Martin Sebor
> Fix For: 4.2
>
>
> The program below aborts at runtime with the latest trunk:
> $ cat t.cpp && nice gmake t && ./t
> #include
> #include
> #include
> int main ()
> {
> const int a[] = { 1, 2, 3, 4, 5, 6 };
> const std::valarray v (a, sizeof a / sizeof *a);
> const std::size_t start = 5;
> std::valarray length (1, 1);
> std::valarray stride (1, 1);
> const std::gslice gsl (start, length, stride);
> const std::valarray vsl = v [gsl];
> assert (a [start] == vsl [0]);
> }
> aCC -c -I/nfs/devco/sebor/dev/stdlib/include/ansi -I/usr/include
> -D_RWSTDDEBUG -mt -D_RWSTD_USE_CONFIG -I/nfs/devco/sebor/dev/stdlib/include
> -I/build/sebor/aCC-3.70-15S/include
> -I/nfs/devco/sebor/dev/stdlib/examples/include -Aa +nostl -g +d +DD64 +w
> +W392 +W655 +W684 +W818 +W819 +W849 t.cpp
> aCC t.o -o t -Aa +nostl -Wl,+s -Wl,+vnocompatwarnings -mt +DD64
> -L/build/sebor/aCC-3.70-15S/lib -lstd15S -lm
> Assertion failed: a [start] == vsl [0], file t.cpp, line 19
> ABORT instruction (core dumped)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-357) [gcc/Mac OS X] link utilities with the iconv library
[ https://issues.apache.org/jira/browse/STDCXX-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor updated STDCXX-357: Component/s: (was: Build) Utilities Priority: Minor (was: Major) Fix Version/s: (was: 4.2) 4.2.1 Issue Type: Improvement (was: Bug) Summary: [gcc/Mac OS X] link utilities with the iconv library (was: [gcc/Mac OS X 10.4.8 Tiger] Some executables need to link with the iconv library.) Changed Issue Type to Improvement, Component(s) to Utilities, set Priority to Minor, and scheduled for 4.2.1. > [gcc/Mac OS X] link utilities with the iconv library > > > Key: STDCXX-357 > URL: https://issues.apache.org/jira/browse/STDCXX-357 > Project: C++ Standard Library > Issue Type: Improvement > Components: Utilities >Affects Versions: 4.1.2, 4.1.3 > Environment: Darwin host.local 8.8.1 Darwin Kernel Version 8.8.1: Mon > Sep 25 19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/RELEASE_I386 i386 i386 >Reporter: Eric Lemings >Assignee: Martin Sebor >Priority: Minor > Fix For: 4.2.1 > > > Some executables (esp. locale-specific utilities) need to link with the iconv > library. Patch listed below. (Don't think it will matter that the link flag > is given for all link commands.) > Index: etc/config/gcc.config > === > --- etc/config/gcc.config (revision 517771) > +++ etc/config/gcc.config (working copy) > @@ -127,7 +129,7 @@ >ifeq ($(OSNAME),Darwin) > # link with gcc_eh to resolve the _Unwind_xxx functions > # (shouldn't we link with it on all platforms?) > -LDLIBS += -lgcc_eh > +LDLIBS += -liconv -lgcc_eh >endif > endif # gcc > 2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-357) [gcc/Mac OS X 10.4.8 Tiger] Some executables need to link with the iconv library.
[ https://issues.apache.org/jira/browse/STDCXX-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533849 ] Martin Sebor commented on STDCXX-357: - I have successfully built the locale utilities with gcc 4.01 on Darwin 8.10.1 w/o iconv (with _RWSTD_NO_ICONV #defined in the config header), probably as a result of http://svn.apache.org/viewvc?view=rev&revision=579018. We should revisit this in the future to see if linking with libiconv provides additional functionality that we might be missing out on now. > [gcc/Mac OS X 10.4.8 Tiger] Some executables need to link with the iconv > library. > - > > Key: STDCXX-357 > URL: https://issues.apache.org/jira/browse/STDCXX-357 > Project: C++ Standard Library > Issue Type: Bug > Components: Build >Affects Versions: 4.1.2, 4.1.3 > Environment: Darwin host.local 8.8.1 Darwin Kernel Version 8.8.1: Mon > Sep 25 19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/RELEASE_I386 i386 i386 >Reporter: Eric Lemings >Assignee: Martin Sebor > Fix For: 4.2 > > > Some executables (esp. locale-specific utilities) need to link with the iconv > library. Patch listed below. (Don't think it will matter that the link flag > is given for all link commands.) > Index: etc/config/gcc.config > === > --- etc/config/gcc.config (revision 517771) > +++ etc/config/gcc.config (working copy) > @@ -127,7 +129,7 @@ >ifeq ($(OSNAME),Darwin) > # link with gcc_eh to resolve the _Unwind_xxx functions > # (shouldn't we link with it on all platforms?) > -LDLIBS += -lgcc_eh > +LDLIBS += -liconv -lgcc_eh >endif > endif # gcc > 2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (STDCXX-357) [gcc/Mac OS X 10.4.8 Tiger] Some executables need to link with the iconv library.
[ https://issues.apache.org/jira/browse/STDCXX-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Sebor reassigned STDCXX-357: --- Assignee: Martin Sebor > [gcc/Mac OS X 10.4.8 Tiger] Some executables need to link with the iconv > library. > - > > Key: STDCXX-357 > URL: https://issues.apache.org/jira/browse/STDCXX-357 > Project: C++ Standard Library > Issue Type: Bug > Components: Build >Affects Versions: 4.1.2, 4.1.3 > Environment: Darwin host.local 8.8.1 Darwin Kernel Version 8.8.1: Mon > Sep 25 19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/RELEASE_I386 i386 i386 >Reporter: Eric Lemings >Assignee: Martin Sebor > Fix For: 4.2 > > > Some executables (esp. locale-specific utilities) need to link with the iconv > library. Patch listed below. (Don't think it will matter that the link flag > is given for all link commands.) > Index: etc/config/gcc.config > === > --- etc/config/gcc.config (revision 517771) > +++ etc/config/gcc.config (working copy) > @@ -127,7 +129,7 @@ >ifeq ($(OSNAME),Darwin) > # link with gcc_eh to resolve the _Unwind_xxx functions > # (shouldn't we link with it on all platforms?) > -LDLIBS += -lgcc_eh > +LDLIBS += -liconv -lgcc_eh >endif > endif # gcc > 2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-435) [Linux] std::codecvt_byname("*.UTF-8").in() to_next greater than expected
[
https://issues.apache.org/jira/browse/STDCXX-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Sebor updated STDCXX-435:
Severity: Incorrect Behavior
Fix Version/s: (was: 4.2)
4.2.1
It's too late to do this in time for 4.2.0. Rescheduled for 4.2.1.
> [Linux] std::codecvt_byname("*.UTF-8").in() to_next greater than expected
> -
>
> Key: STDCXX-435
> URL: https://issues.apache.org/jira/browse/STDCXX-435
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 22. Localization
>Affects Versions: 4.1.3
> Environment: gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)
>Reporter: Mark Brown
>Assignee: Martin Sebor
>Priority: Critical
> Fix For: 4.2.1
>
>
> When compiled with gcc 4.1.1 on Linux the program below runs successfully to
> completion as it should. When compiled with stdcxx the facet returns a
> to_next value that is greater than the number of internal (wchar_t)
> characters actually produced by the conversion and consequently the program
> aborts.
> $ cat t.cpp && make t && ./t
> #include
> #include
> #include
> int main ()
> {
> const std::locale utf8 ("en_US.UTF-8");
> typedef std::codecvt UTF8_Cvt;
> const UTF8_Cvt &cvt = std::use_facet(utf8);
> const char src[] = "abc";
> wchar_t dst [2] = { L'\0' };
> const char* from_next;
> wchar_t* to_next;
> std::mbstate_t state = std::mbstate_t ();
> const std::codecvt_base::result res =
> cvt.in (state,
> src, src + 1, from_next,
> dst, dst + 2, to_next);
> assert (1 == from_next - src);
> assert (1 == to_next - dst);
> assert ('a' == dst [0]);
> }
> gcc -c -I/home/mbrown/stdcxx/include/ansi -D_RWSTDDEBUG
> -I/home/mbrown/stdcxx/include -I/build/mbrown/stdcxx-gcc-4.1.1-11S/include
> -I/home/mbrown/stdcxx/examples/include -pedantic -nostdinc++ -g -W -Wall
> -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align
> t.cpp
> t.cpp: In function 'int main()':
> t.cpp:21: warning: unused variable 'res'
> gcc t.o -o t -L/build/mbrown/stdcxx-gcc-4.1.1-11S/lib -lstd11S -lsupc++ -lm
> t: t.cpp:26: int main(): Assertion `1 == from_next - src' failed.
> Aborted
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [RFC] stdcxx acknowledgments
On Oct 2, 2007 3:01 PM, Martin Sebor <[EMAIL PROTECTED]> wrote: > It occurs to me that we might be able to preempt a potentially > contentious discussion by replacing the stdcxx Acknowledgment > page with one describing the pre-stdcxx history of the project > where we could retain any or all the names from the current > acknowledgment page without having to tackle the delicate issue > of who from the stdcxx community deserves to be mentioned. +1. -- justin
[jira] Commented: (STDCXX-500) 1 + std::deque::iterator ambiguous without debugging iterators
[
https://issues.apache.org/jira/browse/STDCXX-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533824
]
Martin Sebor commented on STDCXX-500:
-
My guess is that distance_type is an alias for int on MSVC/Windows and
gcc/Linux.
Try this:
#include
void foo (std::deque::const_iterator i)
{
i + '\0';
'\0' + i;
i + (short)1;
(short)1 + i;
i + 2;
2 + i;
i + 3L;
3L + i;
}
int main () { }
> 1 + std::deque::iterator ambiguous without debugging iterators
> --
>
> Key: STDCXX-500
> URL: https://issues.apache.org/jira/browse/STDCXX-500
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 24. Iterators
>Affects Versions: 4.1.3
> Environment: HP aCC 6.0
>Reporter: Martin Sebor
>
> Moved from Rogue Wave Bugzilla:
> http://bugzilla.cvo.roguewave.com/show_bug.cgi?id=1923
> Original Message
> Subject: Re: FWD: Peren 6.4 and N + iterator & swap(deque, deque)
> Date: Mon, 18 Apr 2005 18:12:41 -0700 (PDT)
> From: Dennis Handly <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED], [EMAIL PROTECTED]
> CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
> >From: Dennis Handly <[EMAIL PROTECTED]>
> >Or use deque directly:
> template
> inline typename deque<_TypeT, _Allocator>::iterator
> operator+(typename deque<_TypeT,
> _Allocator>::iterator::difference_type __n,
> typename deque<_TypeT, _Allocator>::iterator __rhs)
> {
> return __rhs.operator+(__n);
> }
> This didn't work. I need to also have one for const_iterator.
> And it seems the test is bad:
> error #2349: no operator "+" matches these operands
> operand types are: int + std::deque std::allocator>::const_iterator
> 2+it04
> ^
> 24(9) says that "n denotes a value of difference type Distance".
> So that this has to be "2L". Or better yet:
>...:iterator::difference_type(2) + it04
> Does this seem like something we can get Perennial to change?
> Boris:
> Do we know how those other STLs work? Do they have an extra int
> overloading?
> --- Additional Comments From [EMAIL PROTECTED] 2005-04-19 09:30:12
> Original Message
> Subject: Re: FWD: Peren 6.4 and N + iterator & swap(deque, deque)
> Date: Tue, 19 Apr 2005 10:29:32 -0600
> From: Martin Sebor <[EMAIL PROTECTED]>
> To: Dennis Handly <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
> References: <[EMAIL PROTECTED]>
> Dennis Handly wrote:
> >>From: Dennis Handly <[EMAIL PROTECTED]>
> >>Or use deque directly:
> >
> > template
> > inline typename deque<_TypeT, _Allocator>::iterator
> > operator+(typename deque<_TypeT,
> _Allocator>::iterator::difference_type __n,
> > typename deque<_TypeT, _Allocator>::iterator __rhs)
> > {
> > return __rhs.operator+(__n);
> > }
> >
> > This didn't work. I need to also have one for const_iterator.
> >
> > And it seems the test is bad:
> > error #2349: no operator "+" matches these operands
> > operand types are: int + std::deque > std::allocator>::const_iterator
> > 2+it04
> > ^
> >
> > 24(9) says that "n denotes a value of difference type Distance".
> Ah. That's because the type of 2 is int but deque iterator's
> distance type (that the iterator's type depends on) is long.
> Darn! Those templates, they always get you! I'll have to think
> about this one some more. I created bug 1923 to remind me.
> >
> > So that this has to be "2L". Or better yet:
> >...:iterator::difference_type(2) + it04
> >
> > Does this seem like something we can get Perennial to change?
> Strictly speaking I think the test is incorrect. 24.1, p1 says
> that n (used in Table 76) denotes a value of the difference type
> Distance, but 2 is not. But as a matter of QoI any integer should
> work.
> Martin
> --- Additional Comments From [EMAIL PROTECTED] 2005-04-19 09:31:08
> Here's the test case:
> $ cat t.cpp && aCC -AA -V -c t.cpp
> #include
> void foo (std::deque::const_iterator i)
> {
> i + 2;
> 2 + i;
> }
> aCC: HP aC++/ANSI C B3910B A.06.00 [Aug 25 2004]
> "t.cpp", line 6: error #2349: no operator "+" matches these operands
> operand types are: int + std::deque std::allocator>::const_iterator
> 2 + i;
> ^
> 1 error detected in the compilation of "t.cpp".
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-500) 1 + std::deque::iterator ambiguous without debugging iterators
[
https://issues.apache.org/jira/browse/STDCXX-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533802
]
Farid Zaripov commented on STDCXX-500:
--
Could not reproduce this issue on MSVC8 and gcc 4.2.0/Linux.
> 1 + std::deque::iterator ambiguous without debugging iterators
> --
>
> Key: STDCXX-500
> URL: https://issues.apache.org/jira/browse/STDCXX-500
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 24. Iterators
>Affects Versions: 4.1.3
> Environment: HP aCC 6.0
>Reporter: Martin Sebor
>
> Moved from Rogue Wave Bugzilla:
> http://bugzilla.cvo.roguewave.com/show_bug.cgi?id=1923
> Original Message
> Subject: Re: FWD: Peren 6.4 and N + iterator & swap(deque, deque)
> Date: Mon, 18 Apr 2005 18:12:41 -0700 (PDT)
> From: Dennis Handly <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED], [EMAIL PROTECTED]
> CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
> >From: Dennis Handly <[EMAIL PROTECTED]>
> >Or use deque directly:
> template
> inline typename deque<_TypeT, _Allocator>::iterator
> operator+(typename deque<_TypeT,
> _Allocator>::iterator::difference_type __n,
> typename deque<_TypeT, _Allocator>::iterator __rhs)
> {
> return __rhs.operator+(__n);
> }
> This didn't work. I need to also have one for const_iterator.
> And it seems the test is bad:
> error #2349: no operator "+" matches these operands
> operand types are: int + std::deque std::allocator>::const_iterator
> 2+it04
> ^
> 24(9) says that "n denotes a value of difference type Distance".
> So that this has to be "2L". Or better yet:
>...:iterator::difference_type(2) + it04
> Does this seem like something we can get Perennial to change?
> Boris:
> Do we know how those other STLs work? Do they have an extra int
> overloading?
> --- Additional Comments From [EMAIL PROTECTED] 2005-04-19 09:30:12
> Original Message
> Subject: Re: FWD: Peren 6.4 and N + iterator & swap(deque, deque)
> Date: Tue, 19 Apr 2005 10:29:32 -0600
> From: Martin Sebor <[EMAIL PROTECTED]>
> To: Dennis Handly <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
> References: <[EMAIL PROTECTED]>
> Dennis Handly wrote:
> >>From: Dennis Handly <[EMAIL PROTECTED]>
> >>Or use deque directly:
> >
> > template
> > inline typename deque<_TypeT, _Allocator>::iterator
> > operator+(typename deque<_TypeT,
> _Allocator>::iterator::difference_type __n,
> > typename deque<_TypeT, _Allocator>::iterator __rhs)
> > {
> > return __rhs.operator+(__n);
> > }
> >
> > This didn't work. I need to also have one for const_iterator.
> >
> > And it seems the test is bad:
> > error #2349: no operator "+" matches these operands
> > operand types are: int + std::deque > std::allocator>::const_iterator
> > 2+it04
> > ^
> >
> > 24(9) says that "n denotes a value of difference type Distance".
> Ah. That's because the type of 2 is int but deque iterator's
> distance type (that the iterator's type depends on) is long.
> Darn! Those templates, they always get you! I'll have to think
> about this one some more. I created bug 1923 to remind me.
> >
> > So that this has to be "2L". Or better yet:
> >...:iterator::difference_type(2) + it04
> >
> > Does this seem like something we can get Perennial to change?
> Strictly speaking I think the test is incorrect. 24.1, p1 says
> that n (used in Table 76) denotes a value of the difference type
> Distance, but 2 is not. But as a matter of QoI any integer should
> work.
> Martin
> --- Additional Comments From [EMAIL PROTECTED] 2005-04-19 09:31:08
> Here's the test case:
> $ cat t.cpp && aCC -AA -V -c t.cpp
> #include
> void foo (std::deque::const_iterator i)
> {
> i + 2;
> 2 + i;
> }
> aCC: HP aC++/ANSI C B3910B A.06.00 [Aug 25 2004]
> "t.cpp", line 6: error #2349: no operator "+" matches these operands
> operand types are: int + std::deque std::allocator>::const_iterator
> 2 + i;
> ^
> 1 error detected in the compilation of "t.cpp".
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-228) std::money_{get,put} cannot be instantiated
[
https://issues.apache.org/jira/browse/STDCXX-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533800
]
Farid Zaripov commented on STDCXX-228:
--
Could not repeat this issue. And even ./include/rw/_money.h file doesn't exist.
I suppose that the issue is not actual.
> std::money_{get,put} cannot be instantiated
>
>
> Key: STDCXX-228
> URL: https://issues.apache.org/jira/browse/STDCXX-228
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 22. Localization
>Affects Versions: 4.1.2, 4.1.3
> Environment: all
>Reporter: Martin Sebor
>Priority: Minor
>
> Moved from the Rogue Wave bug tracking database:
> Created By: sebor @ Jun 07, 2001 07:19:12 PM
> The money_get and money_put facets cannot currently be instantiated on a
> user-defined character type:
> $ cat t.cpp
> #include
> int main ()
> {
> std::money_get m;
> }
> $ nice make SRCS=t.cpp
> eccp -c -I/build2/sebor/dev/stdlib/include/ansi --incl_suffixes ::
> -D_RWSTDDEBUG-D_RWSTD_USE_CONFIG -I/build/sebor/eccp-11s/include
> -I/build2/sebor/dev/stdlib/include -I/build2/sebor/dev/stdlib/../rwtest
> -I/build2/sebor/dev/stdlib/tests/include -A -B -x -g
> --display_error_number --diag_suppress 11,450,518 t.cpp
> eccp t.o -o t -L/build/sebor/eccp-11s/lib -lstd11s -lm
> -L/build2/sebor/eccp-11s/tests -lrwtest11s
> C++ prelinker: executing: /usr/local/edg-2.45/bin/eccp -c
> -I/build2/sebor/dev/stdlib/include/ansi --incl_suffixes :: -D_RWSTDDEBUG
> -D_RWSTD_USE_CONFIG -I/build/sebor/eccp-11s/include
> -I/build2/sebor/dev/stdlib/include -I/build2/sebor/dev/stdlib/../rwtest
> -I/build2/sebor/dev/stdlib/tests/include -A -B -x -g --display_error_number
> --diag_suppress 11,450,518 t.cpp
> "/build2/sebor/dev/stdlib/include/rw/_money.h", line 716: error #135: class
> "__rw::__rw_moneypunct_impl" has no member "_C_ivals"
> return &_RW::__rw_moneypunct_impl<_CharT, _Intl>::_C_ivals;
> ^
> detected during:
> instantiation of "const __rw::__rw_moneypunct_init_data<_CharT>
> *std::moneypunct<_CharT, _Intl>::_C_get_ivals() [with
> _CharT=int, _Intl=true]" at line 479 of
> "/build2/sebor/dev/stdlib/include/rw/_locimp.h"
> instantiation of "_Facet *__rw::__rw_create_classic_facet(_Facet
> *) [with _Facet=std::moneypunct]" at line 507
> of "/build2/sebor/dev/stdlib/include/rw/_locimp.h"
> instantiation of "__rw::__rw_facet_base
> *__rw::__rw_facet_maker<_Facet>::_C_maker_func(int,
> const char *, size_t) [with _Facet=std::moneypunct true>]" at line 625 of
> "/build2/sebor/dev/stdlib/include/rw/_locale.h"
> instantiation of "const _Facet &std::use_facet<_Facet>(const
> std::locale &) [with _Facet=std::moneypunct]"
> at line 155 of
> "/build2/sebor/dev/stdlib/include/rw/_money.cc"
> instantiation of "const __rw::__rw_moneypunct_impl_data<_CharT>
>
> &__rw::__rw_money_handler_base_1<_CharT>::_C_get_punct_da
> ta(const std::locale &, bool) [with _CharT=int]" at line
> 308
> instantiation of "__rw::__rw_money_reader<_CharT,
> _InputIter>::__rw_money_reader(_InputIter &, _InputIter
> &, std::ios_base &, bool) [with _CharT=int,
> _InputIter=std::istreambuf_iterator std::char_traits>]" at line 558 of
> "/build2/sebor/dev/stdlib/include/rw/_money.cc"
> instantiation of "std::money_get<_CharT, _InputIter>::iter_type
> std::money_get<_CharT,
> _InputIter>::do_get(std::money_get<_CharT,
> _InputIter>::iter_type, std::money_get<_CharT,
> _InputIter>::iter_type, bool, std::ios_base &,
> std::ios_base::iostate &, long double &) const [with
> _CharT=int, _InputIter=std::istreambuf_iterator std::char_traits>]"
> "/build2/sebor/dev/stdlib/include/rw/_money.h", line 726: error #289: no
> instance of constructor "__rw::__rw_moneypunct_impl<_CharT,
> _Intl>::__rw_moneypunct_impl [with _CharT=int, _Intl=true]" matches
> the argument list
> argument types are: (const __rw::__rw_moneypunct_init_data *)
> _RW::__rw_moneypunct_impl<_CharT, _Intl>(__mp)
> ^
> detected du
[jira] Commented: (STDCXX-250) std::operator>>(istream&, string&) fails to set failbit after it extracts 0 characters
[
https://issues.apache.org/jira/browse/STDCXX-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533797
]
Farid Zaripov commented on STDCXX-250:
--
ChangeLog:
STDCXX-250
* istream.cc (operator>>): Move counter __i out from the try/catch block
and rename to __gcount for consistency with getline(). Set ios_base::failbit
if no characters extracted.
> std::operator>>(istream&, string&) fails to set failbit after it extracts 0
> characters
> --
>
> Key: STDCXX-250
> URL: https://issues.apache.org/jira/browse/STDCXX-250
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 27. Input/Output
>Affects Versions: 4.1.2, 4.1.3
> Environment: all
>Reporter: Martin Sebor
>Priority: Minor
> Fix For: 4.2.1
>
> Attachments: istream.cc.diff
>
>
> 21.3.7.9, p3 says about the string extractor: "If the function extracts no
> characters, it calls is.setstate(ios::failbit), which may throw
> ios_base::failure (27.4.4.3)." The test program below shows that in
> unbuffered mode stdcxx fails to do so when an exception is thrown during the
> third call to underflow().
> $ cat v.cpp && make v && ./v
> #include
> #include
> #include
> #include
> int main ()
> {
> struct: std::streambuf {
> int_type underflow () {
> static int i = 0;
> // i == 0: sgect() invoked from sentry ctor
> // i == 1: sgetc() invoked from operator>>()
> // i == 2: sbumpc() invoked from operator>>()
> return 1 < i++ ? throw i : 'x';
> }
> } buf;
> std::istream is (&buf);
> std::string s;
> is >> s;
> std::printf ("state = %c%c%c, string = \"%s\" (length %u)\n",
> is.rdstate () & is.badbit ? 'B' : '-',
> is.rdstate () & is.eofbit ? 'E' : '-',
> is.rdstate () & is.failbit ? 'F' : '-',
> s.c_str (), s.size ());
> assert ("x" == s);
> assert ((is.failbit | is.badbit) == is.rdstate ());
> }
> gcc -c -I/build/sebor/dev/stdlib/include/ansi -D_RWSTDDEBUG -pthreads
> -D_RWSTD_USE_CONFIG -I/build/sebor/dev/stdlib/include
> -I/build/sebor/gcc-4.1.0-15s/include -I/build/sebor/dev/stdlib/../rwtest
> -I/build/sebor/dev/stdlib/../rwtest/include
> -I/build/sebor/dev/stdlib/tests/include -pedantic -nostdinc++ -g -W -Wall
> -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long v.cpp
> gcc v.o -o v -L/build/sebor/gcc-4.1.0-15s/rwtest -lrwtest15s -pthreads
> -L/build/sebor/gcc-4.1.0-15s/lib -lstd15s -lsupc++ -lm
> state = B--, string = "x" (length 1)
> Assertion failed: (is.failbit | is.badbit) == is.rdstate (), file v.cpp, line
> 30
> Abort (core dumped)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-250) std::operator>>(istream&, string&) fails to set failbit after it extracts 0 characters
[
https://issues.apache.org/jira/browse/STDCXX-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov updated STDCXX-250:
-
Attachment: istream.cc.diff
The patch is attached.
> std::operator>>(istream&, string&) fails to set failbit after it extracts 0
> characters
> --
>
> Key: STDCXX-250
> URL: https://issues.apache.org/jira/browse/STDCXX-250
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 27. Input/Output
>Affects Versions: 4.1.2, 4.1.3
> Environment: all
>Reporter: Martin Sebor
>Priority: Minor
> Fix For: 4.2.1
>
> Attachments: istream.cc.diff
>
>
> 21.3.7.9, p3 says about the string extractor: "If the function extracts no
> characters, it calls is.setstate(ios::failbit), which may throw
> ios_base::failure (27.4.4.3)." The test program below shows that in
> unbuffered mode stdcxx fails to do so when an exception is thrown during the
> third call to underflow().
> $ cat v.cpp && make v && ./v
> #include
> #include
> #include
> #include
> int main ()
> {
> struct: std::streambuf {
> int_type underflow () {
> static int i = 0;
> // i == 0: sgect() invoked from sentry ctor
> // i == 1: sgetc() invoked from operator>>()
> // i == 2: sbumpc() invoked from operator>>()
> return 1 < i++ ? throw i : 'x';
> }
> } buf;
> std::istream is (&buf);
> std::string s;
> is >> s;
> std::printf ("state = %c%c%c, string = \"%s\" (length %u)\n",
> is.rdstate () & is.badbit ? 'B' : '-',
> is.rdstate () & is.eofbit ? 'E' : '-',
> is.rdstate () & is.failbit ? 'F' : '-',
> s.c_str (), s.size ());
> assert ("x" == s);
> assert ((is.failbit | is.badbit) == is.rdstate ());
> }
> gcc -c -I/build/sebor/dev/stdlib/include/ansi -D_RWSTDDEBUG -pthreads
> -D_RWSTD_USE_CONFIG -I/build/sebor/dev/stdlib/include
> -I/build/sebor/gcc-4.1.0-15s/include -I/build/sebor/dev/stdlib/../rwtest
> -I/build/sebor/dev/stdlib/../rwtest/include
> -I/build/sebor/dev/stdlib/tests/include -pedantic -nostdinc++ -g -W -Wall
> -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long v.cpp
> gcc v.o -o v -L/build/sebor/gcc-4.1.0-15s/rwtest -lrwtest15s -pthreads
> -L/build/sebor/gcc-4.1.0-15s/lib -lstd15s -lsupc++ -lm
> state = B--, string = "x" (length 1)
> Assertion failed: (is.failbit | is.badbit) == is.rdstate (), file v.cpp, line
> 30
> Abort (core dumped)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-250) std::operator>>(istream&, string&) fails to set failbit after it extracts 0 characters
[
https://issues.apache.org/jira/browse/STDCXX-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Farid Zaripov updated STDCXX-250:
-
Severity: Incorrect Behavior
Patch Info: [Patch Available]
Fix Version/s: 4.2.1
> std::operator>>(istream&, string&) fails to set failbit after it extracts 0
> characters
> --
>
> Key: STDCXX-250
> URL: https://issues.apache.org/jira/browse/STDCXX-250
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 27. Input/Output
>Affects Versions: 4.1.2, 4.1.3
> Environment: all
>Reporter: Martin Sebor
>Priority: Minor
> Fix For: 4.2.1
>
> Attachments: istream.cc.diff
>
>
> 21.3.7.9, p3 says about the string extractor: "If the function extracts no
> characters, it calls is.setstate(ios::failbit), which may throw
> ios_base::failure (27.4.4.3)." The test program below shows that in
> unbuffered mode stdcxx fails to do so when an exception is thrown during the
> third call to underflow().
> $ cat v.cpp && make v && ./v
> #include
> #include
> #include
> #include
> int main ()
> {
> struct: std::streambuf {
> int_type underflow () {
> static int i = 0;
> // i == 0: sgect() invoked from sentry ctor
> // i == 1: sgetc() invoked from operator>>()
> // i == 2: sbumpc() invoked from operator>>()
> return 1 < i++ ? throw i : 'x';
> }
> } buf;
> std::istream is (&buf);
> std::string s;
> is >> s;
> std::printf ("state = %c%c%c, string = \"%s\" (length %u)\n",
> is.rdstate () & is.badbit ? 'B' : '-',
> is.rdstate () & is.eofbit ? 'E' : '-',
> is.rdstate () & is.failbit ? 'F' : '-',
> s.c_str (), s.size ());
> assert ("x" == s);
> assert ((is.failbit | is.badbit) == is.rdstate ());
> }
> gcc -c -I/build/sebor/dev/stdlib/include/ansi -D_RWSTDDEBUG -pthreads
> -D_RWSTD_USE_CONFIG -I/build/sebor/dev/stdlib/include
> -I/build/sebor/gcc-4.1.0-15s/include -I/build/sebor/dev/stdlib/../rwtest
> -I/build/sebor/dev/stdlib/../rwtest/include
> -I/build/sebor/dev/stdlib/tests/include -pedantic -nostdinc++ -g -W -Wall
> -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long v.cpp
> gcc v.o -o v -L/build/sebor/gcc-4.1.0-15s/rwtest -lrwtest15s -pthreads
> -L/build/sebor/gcc-4.1.0-15s/lib -lstd15s -lsupc++ -lm
> state = B--, string = "x" (length 1)
> Assertion failed: (is.failbit | is.badbit) == is.rdstate (), file v.cpp, line
> 30
> Abort (core dumped)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-250) std::operator>>(istream&, string&) fails to set failbit after it extracts 0 characters
[
https://issues.apache.org/jira/browse/STDCXX-250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533791
]
Farid Zaripov commented on STDCXX-250:
--
But in this test program the operator>>() extracted one character ('x').
Anyway failbit is not set even in case when no characters extracted.
> std::operator>>(istream&, string&) fails to set failbit after it extracts 0
> characters
> --
>
> Key: STDCXX-250
> URL: https://issues.apache.org/jira/browse/STDCXX-250
> Project: C++ Standard Library
> Issue Type: Bug
> Components: 27. Input/Output
>Affects Versions: 4.1.2, 4.1.3
> Environment: all
>Reporter: Martin Sebor
>Priority: Minor
>
> 21.3.7.9, p3 says about the string extractor: "If the function extracts no
> characters, it calls is.setstate(ios::failbit), which may throw
> ios_base::failure (27.4.4.3)." The test program below shows that in
> unbuffered mode stdcxx fails to do so when an exception is thrown during the
> third call to underflow().
> $ cat v.cpp && make v && ./v
> #include
> #include
> #include
> #include
> int main ()
> {
> struct: std::streambuf {
> int_type underflow () {
> static int i = 0;
> // i == 0: sgect() invoked from sentry ctor
> // i == 1: sgetc() invoked from operator>>()
> // i == 2: sbumpc() invoked from operator>>()
> return 1 < i++ ? throw i : 'x';
> }
> } buf;
> std::istream is (&buf);
> std::string s;
> is >> s;
> std::printf ("state = %c%c%c, string = \"%s\" (length %u)\n",
> is.rdstate () & is.badbit ? 'B' : '-',
> is.rdstate () & is.eofbit ? 'E' : '-',
> is.rdstate () & is.failbit ? 'F' : '-',
> s.c_str (), s.size ());
> assert ("x" == s);
> assert ((is.failbit | is.badbit) == is.rdstate ());
> }
> gcc -c -I/build/sebor/dev/stdlib/include/ansi -D_RWSTDDEBUG -pthreads
> -D_RWSTD_USE_CONFIG -I/build/sebor/dev/stdlib/include
> -I/build/sebor/gcc-4.1.0-15s/include -I/build/sebor/dev/stdlib/../rwtest
> -I/build/sebor/dev/stdlib/../rwtest/include
> -I/build/sebor/dev/stdlib/tests/include -pedantic -nostdinc++ -g -W -Wall
> -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long v.cpp
> gcc v.o -o v -L/build/sebor/gcc-4.1.0-15s/rwtest -lrwtest15s -pthreads
> -L/build/sebor/gcc-4.1.0-15s/lib -lstd15s -lsupc++ -lm
> state = B--, string = "x" (length 1)
> Assertion failed: (is.failbit | is.badbit) == is.rdstate (), file v.cpp, line
> 30
> Abort (core dumped)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-582) purify reports memory leak in _rw_bufcat from 0.printf test
[ https://issues.apache.org/jira/browse/STDCXX-582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533680 ] Farid Zaripov commented on STDCXX-582: -- Commited thus: http://svn.apache.org/viewvc?rev=583398&view=rev > purify reports memory leak in _rw_bufcat from 0.printf test > --- > > Key: STDCXX-582 > URL: https://issues.apache.org/jira/browse/STDCXX-582 > Project: C++ Standard Library > Issue Type: Improvement > Components: Tests >Reporter: Travis Vitek >Assignee: Travis Vitek >Priority: Trivial > Fix For: 4.2.1 > > Attachments: stdcxx-582.patch > > > The function test_errno() doesn't deallocate memory allocated inside > rw_sprintfa(). > MLK: 11618 bytes leaked in 256 blocks > * This memory was allocated from: > malloc [rtlib.o] > _rw_bufcat(Buffer&, char const*, unsigned) [printf.cpp:475] > _rw_fmtstr(FmtSpec const&, Buffer&, char const*, unsigned) > [printf.cpp:2399] > _rw_fmterrno(FmtSpec const&, Buffer&, int) [fmt_bits.cpp:1006] > _rw_vasnprintf_c99(FmtSpec*, unsigned, Buffer&, VarArgs*) [printf.cpp:612] > _rw_pvasnprintf(Buffer&, char const*, VarArgs*) [printf.cpp:901] > * Block of 104 bytes at 0x8162138 > * Block of 100 bytes at 0x8161fe0 > * Block of 96 bytes at 0x8162de0 > * Block of 92 bytes at 0x81621f0 > * Block of 86 bytes at 0x8162800 > * Block of 84 bytes at 0x8162c98 > * Block of 82 bytes at 0x8161e00 > [snipped] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
