On Thu, Jan 17, 2008 at 09:02:44PM -0800, David Schwartz wrote: > 3) It is most useful for 'kfree' to be non-const because destroying an > object through a const pointer can easily be done in error. One of the > reasons you provide a const pointer is because you need the function you > pass the pointer to not to modify the object. Since this is an unusual > operation that could be an error, it is logical to force the person doing it > to clearly indicate that he knows the pointer is const and that he knows it > is right anyway.
Freeing a const pointer is not and has never been unusual. It happens all the time for objects whose lifecycle is "initialise at the start, readonly afterwards", of which names, in particular in the form of strings, are a large subset. It also happens in cases of late deletion on refcounted objects, when the main owner (the one who is allowed to change the object and has the non-const pointer) has dropped its reference, but some object needs a readonly instance a little longer. Think virtual files in proc, sysfs or friends kept open after the underlying information source, often a device, is gone. 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/