Issue Details (XML | Word | Printable)

Key: STDCXX-856
Type: Bug Bug
Status: Open Open
Priority: Critical Critical
Assignee: Unassigned
Reporter: Martin Sebor
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
C++ Standard Library

[Sun C++] data corruption in rw_printf() with "%{$VAR!:@}", "%A{*c}", and "%{@}"

Created: 11/Apr/08 11:49 PM   Updated: 02/Dec/08 03:05 AM
Return to search
Component/s: Test Driver
Affects Version/s: 4.2.0
Fix Version/s: 4.2.2

Time Tracking:
Original Estimate: 2h
Original Estimate - 2h
Remaining Estimate: 2h
Time Spent - 4h Remaining Estimate - 2h
Time Spent: 4h
Time Spent - 4h Remaining Estimate - 2h

Environment: Sun C++ 5.9/Solaris 10/AMD64
Issue Links:
Blocker
 
Reference
 

Severity: Runtime Error


 Description  « Hide
When compiled with Sun C++ (both 5.9 and 5.8) in 15S build mode the program below exits with SIGABRT. It runs fine when compiled with HP aCC 3.73 or gcc 4.1.1 on Linux/x86_64 (both in wide mode). I suspect it might have something to do with STDCXX-828.
$ cat t.cpp && gmake t && ./t
#include <cassert>
#include <cstring>
#include <rw_printf.h>

int main ()
{
    char buf [80];
    rw_sprintf (buf, "%{$FUNCALL!:@}",
                "%{*Ac} %s %{@}",
                1, " ", "foo", "%Lg", 9.0L);

    rw_printf ("%{$FUNCALL}\n");

    assert (0 == std::strcmp (buf, "\" \" foo 9"));
}
CC -c -D_RWSTDDEBUG   -mt -I/amd/devco/sebor/stdcxx/include -I/build/sebor/stdcxx-suncc-5.8-j13-15S/include -I/amd/devco/sebor/stdcxx/tests/include  -library=%none -g  -xarch=amd64 +w -errtags -erroff=hidef   t.cpp
CC t.o -o t -L/build/sebor/stdcxx-suncc-5.8-j13-15S/rwtest -lrwtest15S -library=%none  -mt  -xarch=amd64 -L/build/sebor/stdcxx-suncc-5.8-j13-15S/lib  -lstd15S  -lm 
" " foo 1.69951e-4944
Assertion failed: 0 == std::strcmp (buf, "\" \" foo 9"), file t.cpp, line 14
Abort (core dumped)


 All   Comments   Work Log   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Martin Sebor added a comment - 11/Apr/08 11:50 PM
Possibly related to STDCXX-856.

Martin Sebor added a comment - 11/Apr/08 11:53 PM
Same problem in 4.2.0 so this is not a regression.

Martin Sebor added a comment - 14/Apr/08 03:15 AM
Caused by the compiler bug described in STDCXX-861. I can't think of a workaround so it looks like STDCXX-861 blocks all progress on this issue...

Martin Sebor added a comment - 14/Apr/08 03:20 AM
Need at least 2 more hours to see if a workaround is even possible...