Hi Simon,
On Wed, 4 Mar 2020 at 13:45, Simon Goldschmidt simon.k.r.goldschmidt@gmail.com wrote:
Am 20.02.2020 um 04:05 schrieb Simon Glass:
On Wed, 19 Feb 2020 at 12:39, Simon Goldschmidt simon.k.r.goldschmidt@gmail.com wrote:
Commit cfda60f99ae2 ("sandbox: Use a prefix for all allocation functions") introduced preprocessor macros for malloc/free etc.
This is bad practice as it essentially makes 'free' a reserved keyword and resulted in quite a bit of renaming to avoid that reserved keyword.
A better solution is to define the allocation functions as 'static inline'.
As a side effect, exports.h must not export malloc/free for sandbox.
Signed-off-by: Simon Goldschmidt simon.k.r.goldschmidt@gmail.com
A side-effect is that exports.h may not declare malloc/free. I'm not really sure if this is correct, but for sandbox, it should probably be ok?
Is it possible to fix this? E.g. don't use inline for these two functions on sandbox?
Not using inline for sandbox for these two is *not* an option as these two are exactly the ones offending globally known names.
I guess we have to know what we want here: what is exports.h meant for? To me it looks like it is meant for "U-Boot API" applications to link against. If so, why is it included in U-Boot sources (in over 20 files)?
I guess one solution would be to move (or copy) the DL prefix handling into exports.h and _exports.h so that applications linking with exports.h implicily call dlmalloc/dlfree, not malloc/free (which would be the OS versions for sandbox).
I'll try to prepare v2 in that direction, but I'm still not unsure since exports.h is included in internal U-Boot code.
OK sounds good. I do wonder whether we should drop the exports.h inclusions as part of this? It does seem odd. OR perhaps they are there just to make sure that the functions match the API?
Regards, Simon