Attention is currently required from: Raul Rangel. Julius Werner has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/56002 )
Change subject: lib/cbfs,commonlib/mem_pool: Make cbfs_free take const pointer ......................................................................
Patch Set 1: Code-Review-1
(1 comment)
Patchset:
PS1: While pretty harmless, I'm not sure this is the right thing to do from a design purity point of view. free() in the C standard library doesn't take a const pointer either, after all. Conceptually const means "you may not modify the data pointed to by this pointer", or in other words "I can pass this const pointer around to whatever function I want and I don't need to care what exactly they do with it, I can trust that afterwards I can still use the data in there and it didn't change". free() is explicitly _not_ doing that -- what free() does is make it illegal to ever access the pointed-to data again afterwards. So while it may technically not write to the pointer in our allocator implementation, I would say that conceptually free() is much more similar to a write operation than a read operation, and allowing it on const pointers would undermine that "guarantee" that const is supposed to provide.
Is there any really good technical reason why you need to have this (as opposed to just rewriting calling functions to make the variables passed to this non-const)?