Martin Sebor wrote: > That means that the compiler doesn't always zero-initialize objects of POD-type. [...]
Regarding to _RW::__nullref: >>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. In our case the _RWSTD_NO_POD_ZERO_INIT is defined. So, is it possible that _RW::__nullref' s fields may contain non-zero values after the initialization? If yes, maybe, it will be useful to zero this memory manually to avoid this problem in any case? Thanks, Anton Pevtsov. -----Original Message----- From: Martin Sebor [mailto:[EMAIL PROTECTED] Sent: Thursday, April 06, 2006 18:46 To: [email protected] Subject: Re: Problems with 0-lengths strings after an exception thrown in 11s configuration Anton Pevtsov wrote: > Martin, I discovered that on Windows, MSVC 7.1 the config.h defines > _RWSTD_NO_POD_ZERO_INIT That means that the compiler doesn't always zero-initialize objects of POD-type. E.g., in const UserChar eos = UserChar (); or in UserChar eos; eos = UserChar (); eos may not be all zeros. > > 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? Yes. When the macro is #defined. Martin > > Thanks, > Anton Pevtsov. > > > -----Original Message----- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Friday, March 31, 2006 21:00 > To: [email protected] > 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
