This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC][BZ #16009] Memory handling in strxfrm_l()


Some additional comments to OP.

On Thu, Nov 20, 2014 at 12:10:29PM +0100, Leonhard Holz wrote:
> Hello everybody,
> 
> by reading through the strxfrm_l function to solve a possible buffer
> overflow bug (https://sourceware.org/bugzilla/show_bug.cgi?id=16009)
> I found some other improvable things and would like to have some
> feedback how to proceed.
> 
> 1. Line 133: Empty string handling. This could be placed at the very
> start of the function. Instead of determining the strlen() of the
> input one could check if the first byte is \0 -> faster special
> path.
> 
That would not likely help as probability of transforming empty strings 
is close to zero. It could harm nonempty case as for first byte check
you need to do load+compare instruction versus only compare after
strlen.

Second point here is that speed is not primary concern as you use this
to replace many strcoll calls with strcmp.

> 
> 6. Use the given parameter n instead of srclen = strlen(src) for
> computing the buffer size. Since only n bytes are written into dst
> the number of weights and rules to cache should be limited by this
> parameter and calling strlen could be avoided. Does this sound
> reasonable?
> 
You cannot avoid strlen as you need to return size of converted string.
It is hard to compute exact length as to save space we compress weights
with utf8 encoding. However it should be possible to calculate size
without using cache.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]