stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anton Pevtsov" <Ant...@moscow.vdiweb.com>
Subject RE: Problems with 0-lengths strings after an exception thrown in 11s configuration
Date Wed, 05 Apr 2006 14:54:13 GMT
Martin, I discovered that on Windows, MSVC 7.1 the config.h defines
_RWSTD_NO_POD_ZERO_INIT

On Unix with gcc 4.0.2 _RWSTD_NO_POD_ZERO_INIT is not defined.

Does this mean that we may get a POD containing non-zero values?

Thanks,
Anton Pevtsov.


-----Original Message-----
From: Martin Sebor [mailto:sebor@roguewave.com] 
Sent: Friday, March 31, 2006 21:00
To: stdcxx-dev@incubator.apache.org
Subject: Re: Problems with 0-lengths strings after an exception thrown
in 11s configuration


Anton Pevtsov wrote:

> The following code works incorrectly on Windows, compiler MSVC-7.1. 
> But the problem is unstable, so I am not sure that this test will fail

> everywhere.

It would be good to test on other platforms. I expect to have access to
UNIX while traveling but debugging anything on Windows might be
difficult. [...]
> out_of_range cougth
> string size is 677733217 for string (null), expected 0 bad_alloc 
> cougth
> 
> The problem seems to be in the _RW::__nullref dereferencing - its 
> fields contains garbage.

That should never happen. The object is a POD and should be all zeros.

> I found that __nullref is declared as
> 
> extern _RWSTD_EXPORT unsigned long __nullref [];
> And intialized as:
> _RWSTD_EXPORT unsigned long __nullref [sizeof (StringRef) / 4 + 2];
> 
> Is it correct to cast it to _RW::__null_ref<_CharT, _Traits, 
> _Allocator> and use fileds of this class after the cast?

I believe so. The __null_ref object represents the empty string whose
all members are 0. This is a hack for Windows not collapsing static data
members of a class template into a single instance across shared library
boundaries. Since you're using an archive library this shouldn't even be
an issue.

> Also the sample works OK if I just throw out_of_range exception 
> instead of the s.insert (10, wstr, str_len); call...

So there seems to be a difference in behavior between throwing from
within the library and from the test itself. I would try throwing
directly from within the test but by calling the
__rw_throw() function to see if it changes things. There might be an
issue there.

> 
> Martin, could you look into this when you have a chance, please?

I'll try but I may not have much time until I get back. If this is
stopping you from making progress you might want to either switch to
Linux or put the exception tests on the back burner and move on to the
other string tests.

Martin


Mime
View raw message