I guess never mind the UMR/RUI question. The dbx RUI is probably
caused by a compiler (or dbx) bug. It would be interesting to do
a comparison with gcc to see if dbx also complains about an RUI.
Here's my test case for the bug:
http://issues.apache.org/jira/browse/STDCXX-87?focusedCommentId=12580
Travis Vitek wrote:
Martin Sebor wrote:
Travis Vitek wrote:
Martin Sebor wrote:
I suspect the SEGV discussed in the thread below is due to the patch
for STDCXX-216: http://svn.apache.org/viewcvs?view=rev&rev=616673
Reverting the patch makes the error go away. Travis, can you look
into it w
Martin Sebor wrote:
>
> Travis Vitek wrote:
>>
>>
>> Martin Sebor wrote:
>>> I suspect the SEGV discussed in the thread below is due to the patch
>>> for STDCXX-216: http://svn.apache.org/viewcvs?view=rev&rev=616673
>>>
>>> Reverting the patch makes the error go away. Travis, can you look
>>>
Travis Vitek wrote:
Martin Sebor wrote:
I suspect the SEGV discussed in the thread below is due to the patch
for STDCXX-216: http://svn.apache.org/viewcvs?view=rev&rev=616673
Reverting the patch makes the error go away. Travis, can you look
into it when you have a moment please?
Thanks
Marti
Martin Sebor wrote:
>
> I suspect the SEGV discussed in the thread below is due to the patch
> for STDCXX-216: http://svn.apache.org/viewcvs?view=rev&rev=616673
>
> Reverting the patch makes the error go away. Travis, can you look
> into it when you have a moment please?
>
> Thanks
> Martin
>
Martin Sebor wrote:
>
> I suspect the SEGV discussed in the thread below is due to the patch
> for STDCXX-216: http://svn.apache.org/viewcvs?view=rev&rev=616673
>
> Reverting the patch makes the error go away. Travis, can you look
> into it when you have a moment please?
>
> Thanks
> Martin
>
Just to verify, changing
slocname = (char*)std::malloc (16384);
to
slocname = new char[16384];
is sufficient?
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Thursday, March 20, 2008 2:36 PM
> To: dev@stdcxx.apache.org
> Subject: Re
FYI: This was simple enough that I made the change myself:
http://svn.apache.org/viewvc?rev=639452&view=rev
Martin
Martin Sebor wrote:
Scott Zhong wrote:
Martin, would you suggest that there should be a check after malloc and
throw bad_alloc?
I think we should just use the new expression i
Scott Zhong wrote:
Martin, would you suggest that there should be a check after malloc and
throw bad_alloc?
I think we should just use the new expression instead of calling
malloc. That way we don't need to check. Unless we call malloc()
in the rest of the program for some reason.
Martin
-
Interesting.
I boiled these observations down to a simple little test case.
[EMAIL PROTECTED] exceptions]$ cat lib1.cpp
#include
#define STRINGIZE(x) _STRINGIZE(x)
#define _STRINGIZE(x) #x
void f () {
const char* s = "file " __FILE__ ", line
Martin, would you suggest that there should be a check after malloc and
throw bad_alloc?
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Thursday, March 20, 2008 12:02 PM
> To: dev@stdcxx.apache.org
> Subject: Re: [TESTCASE] STDCXX-750
I was going to say this is the same bug as STDCXX-764:
http://issues.apache.org/jira/browse/STDCXX-764
but after looking at it more closely I believe the compiler
is correct in this case because malloc() returns 0 when it
fails to allocate memory. The warning could be clearer about
it.
Martin
This will silence the warnings but I think we might be able to do
better than simply returning from the function. It seems to me,
based on the LC_TIME Locale Definition in POSIX (see below) that
when strtok() returns 0 in the cases below it indicates invalid
input. I think we should diagnose it as
cat /build/scottz/t2.cpp && aCC -V && aCC -c +w /build/scottz/t2.cpp
#include
int main()
{
static char * test = 0;
if (!test) {
test = (char *)std::malloc (12345);
*test = '\0';
}
return 0;
}
aCC: HP C/aC++ B3910B A.06.16 [Nov 26 2007]
"/build/scottz/t2.cpp", line 8, procedu
Index: time.cpp
===
--- time.cpp(revision 634377)
+++ time.cpp(working copy)
@@ -67,12 +67,16 @@
// now get the offset
tokp = std::strtok (0, ":");
+if (NULL == tokp)
+return;
std::sscanf (tokp, "%d
I suspect the SEGV discussed in the thread below is due to the patch
for STDCXX-216: http://svn.apache.org/viewcvs?view=rev&rev=616673
Reverting the patch makes the error go away. Travis, can you look
into it when you have a moment please?
Thanks
Martin
Martin Sebor wrote:
Mark Wright wrote:
Here's my proposed list of platforms for 4.2.1. I don't think we can
quite meet the release goals outlined in the release policy (I don't
see us cleaning up all the test failures and warnings on all Primary
platforms) but we might as well try to use the process to the extent
we can.
Let me know i
Travis Vitek wrote:
Eric Lemings wrote:
Greetings,
I've been stepping through one of the string tests. The
std::string::at() member function is being called with a __pos value
that is >= size() causing the _RWSTD_REQUIRES assertion to fail. It
seems to be throwing an exception, which is n
Martin Sebor wrote:
There are some platforms where an exception thrown from a shared
lib can't be caught in another executable. I vaguely recall that
OS X may be one of them (maybe only under certain conditions).
FWIW, here's some background on this issue I found online:
http://lists.apple.com/
There are some platforms where an exception thrown from a shared
lib can't be caught in another executable. I vaguely recall that
OS X may be one of them (maybe only under certain conditions).
Martin
Eric Lemings wrote:
-Original Message-
From: Travis Vitek [mailto:[EMAIL PROTECTED]
> -Original Message-
> From: Travis Vitek [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 19, 2008 10:50 PM
> To: dev@stdcxx.apache.org
> Subject: RE: _RWSTD_REQUIRES throwing uncaught exceptions in tests?
>
>
>
> > Eric Lemings wrote:
> >
> > Greetings,
> >
> > I've been stepp
21 matches
Mail list logo
