Michael Meeks wrote:
Hi Stephan,
[...]
- Why #ifdef __GNUC__ and not let the compiler bark if not C99?
Because we're doing some odd compiler-dependent stuff I guess.
That's my point here: we are doing stuff available at least on every C99
compiler. But probably not worth discussing further...
- Why RTL_CONSTASCII_USTRINGPARAM_STR indirection? Should be documented
because if you don't use this trick if you do:
#define FOO "baa"
You end up with an error: undefined LFOO from the L##param paste, this
removes that issue :-)
Oops, yes.
- At least for C++, the type definition within the compound literal
expression within the cast expression in RTL_CONSTASCII_USTRINGPARAM is
dubious, as C++ requires that no types are defined in cast expressions
(a C++ template could be used instead).
Luckily this is inside a GNU conditional, and g++ allows several
extensions to the standard here (as you see). If you have some clever
template way of doing this, please do so - I've no idea how to do it :-)
It would boil down to an additional
template< ::std::size_t N > struct S { sal_Int32 c,l; wchar_t b[N]; };
and using an instantiation of that in the compound literal, but only
#ifdef __cplusplus, of course...
snip a ton of documentation fixes: feel free to just do / commit these
- it would prolly be easier than writing the mail here. The CWS is (as
yet) not finished, so it's no suprise.
But why then are all issues RESOLVED/FIXED? ;) Anyway, can try to
remember to apply my list once things have settled.
[...]
- Why is the refCount SAL_STRING_STATIC_FLAG|1 instead of just
SAL_STRING_STATIC_FLAG?
- Why is the refCount SAL_STRING_STATIC_FLAG|1 instead of just
SAL_STRING_STATIC_FLAG?
Why not ?
Unnecessary complexity. :)
[...]
- Why SAL_STRING_INTERN_FLAG? Why not change
rtl_uString_intern_internal so that it works correctly on already
interned strings.
It works correctly anyway; obviously the bit is necessary for string
destruction: this is not yet implemented (you're reviewing a
work-in-progress CWS). The purpose of the bit should be obvious & should
follow from a few seconds thought wrt. the cost of a lock take / hash
lookup on every string destruction ;-)
Oops, yes, sure.
- The position of the first OSL_DOUBLE_CHECKED_LOCKING_MEMORY_BARRIER in
getInternalMutex is wrong. Any potential memory writes in
osl_createMutex must be moved before the barrier, only the memory write
to pPoolGuard must be after the barrier.
Fix it.
Me? You? Who?
Having said that - this code is copied from rtl's instance.hxx so,
presumably the same problem needs fixing there too ?
All the code in instance.hxx:1.8 correctly does
temp = ...some writes...;
OSL_DOUBLE_CHECKED_LOCKING_MEMORY_BARRIER();
p = temp; // final write
-Stephan
[...]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
