[PATCH 1/8] malloc: implement USE_DL_PREFIX via inline functions

Tom Rini trini at konsulko.com
Wed Mar 4 21:49:55 CET 2020


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.goldschmidt at 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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200304/d946466e/attachment.sig>


More information about the U-Boot mailing list