Request for approval: Bug 100057 - Potential stack corruption in GetJavaProperties
Alan.Bateman at Sun.COM
Fri May 22 17:30:23 UTC 2009
Andrew Haley wrote:
> I've reworked the patch.
> I tried to refactor the code to make it cleaner and easier to follow,
> but I ended up touching so many places that it bacame a major change,
> and there's no way I could possibly test it all, especially the special
> cases for Solaris.
> So, I backed off and produced this, the minimum patch. encoding_variant
> and temp are malloc()d to the size that they need, and temp is realloc()d,
> as you suggest.
This looks much better except the size when allocating encoding_variant.
If I read the patch correctly then encoding_variant is malloc'ed before
'p' is initialized (or 'p' might actually be null in the Solaris case
when not a euro locale). Do I have this right? strlen(temp)+1 would work
but would allocate a bit more than you need. A minor nit is that a
malloc failure will return without freeing temp but I wouldn't worry
about this because this is called once during startup and we won't get
too far if heap is completely exhausted.
More information about the core-libs-dev