[Stlport-devel] Borland's problem/suggestion

[Petr O. <pt...@is...>]

Dear incognito,

Why not post following message to stlport-devel list? And why you keep thread
and Subject 'Fw: [Stlport-devel] etc/ChangeLog' for totally different topic?


As about Borland, I'm not interesting Windows platform. This is François's
territory.

Discussion/explanation are welcome, but patch required (via patch submitting
on SourceForge): otherwise I don't see the discussion issue.

Bests,

   - ptr


> Ptr,
>
> Here's a summary of the rationale for my most recent contributions.  Not
> sure if this would be of particular interest to the entire STLport
> development community.  I'm happy to write ChangeLog entries for these or
> annotate the code, whichever STLport prefers.
>
> All of these changes relate to Borland errors in locale unit tests where
> "string veryLongFacetName" is declared inside a try block and
> _M_throw_on_creation_failure is called.  This might not ultimately prove to
> be the best solution, but at least it's an intermediate solution that allows
> Borland compilers to pass locale unit tests.
>
> In stlport/stl/_threads.h, I added a destructor for _Refcount_Base. Without
> this change, when string veryLongFacetName is used and
> _M_throw_on_creation_failure is called, Borland fails to acquire a lock in
> _STLP_mutex_spin<__inst>::_M_do_lock when _STLP_ACQUIRE_LOCK(__l->_M_lock)
> is called in __stl_debug_engine<_Dummy>::_M_detach.  When this happens,
> stldbg version of stl_unit_test.exe goes into an infinite loop between
> _STLP_mutex_spin<__inst>::_M_do_lock and
> _STLP_mutex_spin<__inst>::_S_nsec_sleep.
>
> In stlport/stl/debug/_iterator.h, I added a destructor for
> __construct_checker for the same reason.
>
> In /src/time_facets.cpp and stlport/stl/_time_facets.h, I made _M_timeinfo
> static.  Otherwise, Borland creates a new instance of _Time_Info whenever
> time_init is inherited in time_put, time_get, and whenever a time_init
> constructor are called.  Apparently, this causes a problem during destructor
> cleanup when _M_throw_on_creation_failure is called in time_by_name in
> stldbg build. When _M_throw_on_creation_failure is called, Borland fails
> time_by_name unit test with STL assertion failure : __next &&
> __next->_Owner() == __l in __stl_debug_engine<_Dummy>::_M_detach.
> 
> These changes also seem to avoid a "Deallocating a block that was never
> allocated" error.
>
> These changes don't appear to affect any other unit tests with Borland's
> free compiler.  With 5.2 trunk svn update 3514, I'm getting one error (known
> StandAlone bug) and 4 ignores in release, debug and stldbg unit tests.  I
> haven't had a chance to test this workaround with more recent Borland
> compilers, but plan to soon.