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: alloca vs malloc


On Sat, 17 May 2014, Ondrej Bilka wrote:

> For libc there are better alternatives, I will add priority to malloca
> cleanup. As glibc code is now alloca are mostly
> trivial or following this pattern occuring about hundred times:

I suggest doing such cleanup in a maximally conservative and incremental 
way:

* If you can identify an existing pattern that can be abstracted (with a 
macro or inline function) in such a way that the code generated does not 
change at all, the change is safer and easier to review than one that 
causes lots of changes to code generation - even if you then end up with 
several different macro / inline function abstractions for slightly 
different existing patterns, and there is then a followup stage where a 
preferred pattern is chosen and other variants converted over to it.

* If checks are inserted where missing then:

  - Deal with separate cases separately rather than having a big patch 
    with lots of separate changes each of which needs individual review.

  - For each such case of a missing check, file a bug in Bugzilla and try 
    to give some indication of the circumstances in which overflow might 
    occur.  (Sometimes there may be reasons like "this can't actually 
    overflow on Linux because Linux limits the total size of the 
    environment" or similar - given that glibc supports more than Linux 
    and it shouldn't necessarily be presumed such limits will stay in 
    Linux in future, such cases should still be fixed in line with the GNU 
    principle of avoiding arbitrary limits.)  I expect distribution 
    security people will then want to look at these bugs in more detail to 
    decide if there should be a CVE.

  - New checks should follow the patterns with the widest existing 
    practice in glibc rather than e.g. using __int128 or saturating 
    arithmetic.  It's quite possible some other form is in fact more 
    efficient, but using the existing style is more conservative - once 
    all such checks are using just a few macros / inline functions, any 
    change to the style of the checks can be considered as a separate 
    matter from adding the checks.

* Likewise in cases where checks are present but incorrect.

Yes, this inevitably means a large number of small patches (and lots of 
bugs in Bugzilla for fairly obscure issues) - I think it's best if the 
only big patches in this area are ones that don't change the code 
generated for installed shared libraries at all.

-- 
Joseph S. Myers
joseph@codesourcery.com


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