On Wed, Mar 04, 2020 at 09:44:27PM +0100, Simon Goldschmidt wrote: > Am 20.02.2020 um 04:05 schrieb Simon Glass: > > On Wed, 19 Feb 2020 at 12:39, Simon Goldschmidt > > <simon.k.r.goldschm...@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.goldschm...@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)?
Yes, it's for API users. But, we also need to be sure our exported functions have the right calling interface. So I suspect a whole lot less files should be including it, and we could have a single place to confirm our exported functions have the right ABI, but not also use this file in so many places? -- Tom
signature.asc
Description: PGP signature