On 06/20/2012 10:22 PM, Caolán McNamara wrote:
I wonder if there would be any actual measurable performance benefit to
sticking in some hackery to keep the rtl_str_getLength symbol for
backwards compatibility but alias/define rtl_str_getLength to strlen in
order to get any benefit of those optimi
On Wed, 2012-06-20 at 14:48 +0200, Stephan Bergmann wrote:
> rtl_str_getLength
I wonder if there would be any actual measurable performance benefit to
sticking in some hackery to keep the rtl_str_getLength symbol for
backwards compatibility but alias/define rtl_str_getLength to strlen in
order to
On 06/18/2012 05:50 PM, Caolán McNamara wrote:
I bet this is one if the false-positive occasions where valgrind isn't
aware of one of the strlen performance hacks IIRC where glibc knows that
it can get away with traversing that strdup's memory block in 4byte
chunks in its strlen e.g. someone with
On Mon, 2012-06-18 at 13:41 +0200, Stephan Bergmann wrote:
> In either case, the strdup(aUser.getStr()) should be OK?
I bet this is one if the false-positive occasions where valgrind isn't
aware of one of the strlen performance hacks IIRC where glibc knows that
it can get away with traversing that
On 06/15/2012 05:45 PM, Marc-André Laverdière wrote:
Here is a patch for a small fish I caught while valgrinding. It was
accessing memory in the strdup.
Was it really? My reading of the original
rtl::OUString aUserName;
rtl::OString aUser;
oslSecurity aSec = osl_getCu
Here is a patch for a small fish I caught while valgrinding. It was
accessing memory in the strdup.
Marc-André LAVERDIÈRE
"Perseverance must finish its work so that you may be mature and complete,
not lacking anything." -James 1:4
http://asimplediscipleslife.blogspot.com/
mlaverd.theunixplace.com
