Request for approval: Bug 100057 - Potential stack corruption in GetJavaProperties

Alan Bateman 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 mailing list