On Fri, Jan 18, 2008 at 05:45:49PM +0100, [EMAIL PROTECTED] wrote: > The malloc attribute is exactly about this : giving the compiler the > indication that no other pointer aliases this object, allowing for > better optimizations.
If you put a malloc attribute on the allocator and no free attribute on the deallocator, you can get bugs indeed. GIGO. > Yes. Bad things start to happen when users add wrong indications to > the compiler. By adding the "const" indication to kfree(), the programmer > wrongly tells that it can optimize reading the values pointed to before or > after calling the function (if it is also sure that they cannot be > read/written otherwise). Current gcc implementations seem quite > conservative in this regard, and don't optimize that much, but what about > the future? The future should be quite nice because: - the compiler can not know that kmalloc does not have an alias to the pointer tucked somewhere accessible by other non-inline functions (as kfree is), especially since it does have aliases in practice, so it cannot prove to "not read/written otherwise" part without the malloc attribute - if you add the (non-standard C) malloc attribute to kmalloc, then you also add the free attribute to kfree which tells the compiler that the pointer is invalid after the call, which ensures no accesses will be moved after it OG. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
