[U-Boot] [PATCH 02/10] Add some standard headers external code might need

[Simon Glass]

Hi Masahiro,

On 30 October 2014 01:53, Masahiro Yamada <yamada.m at jp.panasonic.com> wrote:
> Hi Simon,
>
>
>
> On Wed, 29 Oct 2014 19:43:26 -0600
> Simon Glass <sjg at chromium.org> wrote:
>
>> Hi Masahiro,
>>
>> On 29 October 2014 08:06, Masahiro YAMADA <yamada.m at jp.panasonic.com> wrote:
>> > Hi Simon,
>> >
>> > 2014-10-29 3:24 GMT+09:00 Simon Glass <sjg at chromium.org>:
>> >> Hi,
>> >>
>> >> On 28 October 2014 11:46, Jeroen Hofstee <jeroen at myspectrum.nl> wrote:
>> >>> Hello Simon,
>> >>>
>> >>>
>> >>> On 28-10-14 18:33, Simon Glass wrote:
>> >>>>
>> >>>> Hi Masahiro,
>> >>>>
>> >>>> On 28 October 2014 10:38, Masahiro YAMADA <yamada.m at jp.panasonic.com>
>> >>>> wrote:
>> >>>>>
>> >>>>> Hi Simon,
>> >>>>>
>> >>>>>
>> >>>>> 2014-10-29 1:29 GMT+09:00 Simon Glass <sjg at chromium.org>:
>> >>>>>>
>> >>>>>> Hi Masahiro,
>> >>>>>>
>> >>>>>> On 28 October 2014 10:25, Masahiro YAMADA <yamada.m at jp.panasonic.com>
>> >>>>>> wrote:
>> >>>>>>>
>> >>>>>>> Hi Gabe, Simon,
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> 2014-10-15 19:38 GMT+09:00 Simon Glass <sjg at chromium.org>:
>> >>>>>>>>
>> >>>>>>>> From: Gabe Black <gabeblack at chromium.org>
>> >>>>>>>>
>> >>>>>>>> inttypes.h defines format specifiers for printf which work with data
>> >>>>>>>> types of
>> >>>>>>>> particular sizes. stdlib.h is currently just a passthrough to malloc.h
>> >>>>>>>> which
>> >>>>>>>> has declarations of the various *alloc functions.
>> >>>>>>>>
>> >>>>>>>> Add the required #define to common.h so that these printf format
>> >>>>>>>> specifiers
>> >>>>>>>> will be made available.
>> >>>>>>>>
>> >>>>>>>> Signed-off-by: Gabe Black <gabeblack at google.com>
>> >>>>>>>> Reviewed-by: Gabe Black <gabeblack at chromium.org>
>> >>>>>>>> Tested-by: Gabe Black <gabeblack at chromium.org>
>> >>>>>>>> Reviewed-by: Bill Richardson <wfrichar at google.com>
>> >>>>>>>> Signed-off-by: Simon Glass <sjg at chromium.org>
>> >>>>>>>> (Replaced with a GPL version from glibc)
>> >>>>>>>>
>> >>>>>>> [snip]
>> >>>>>>>>
>> >>>>>>>> diff --git a/include/stdlib.h b/include/stdlib.h
>> >>>>>>>> new file mode 100644
>> >>>>>>>> index 0000000..6bc7fbb
>> >>>>>>>> --- /dev/null
>> >>>>>>>> +++ b/include/stdlib.h
>> >>>>>>>> @@ -0,0 +1,12 @@
>> >>>>>>>> +/*
>> >>>>>>>> + *  Copyright (C) 2013 Google Inc.
>> >>>>>>>> + *
>> >>>>>>>> + * SPDX-License-Identifier:    GPL-2.0+
>> >>>>>>>> + */
>> >>>>>>>> +
>> >>>>>>>> +#ifndef __STDLIB_H_
>> >>>>>>>> +#define __STDLIB_H_
>> >>>>>>>> +
>> >>>>>>>> +#include <malloc.h>
>> >>>>>>>> +
>> >>>>>>>> +#endif /* __STDLIB_H_ */
>> >>>>>>>> --
>> >>>>>>>> 2.1.0.rc2.206.gedb03e5
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> This patch is not clear to me.
>> >>>>>>>
>> >>>>>>> Why do we need include/stdlib.h ?
>> >>>>>>
>> >>>>>> This makes the U-Boot environment more similar to that used by other
>> >>>>>> software, so we can more easily build it without lots of glue files.
>> >>>>>> Normally stdlib.h defines malloc() and friends.
>> >>>>>
>> >>>>> I am not happy about this.
>> >>>>>
>> >>>>> Our right direction is to make U-Boot environment more similar to the
>> >>>>> Kernel, I think.
>> >>>>>
>> >>>>> stdlib.h shouldn't appear in bare metal code.
>> >>>>
>> >>>> That's right, we don't want to include this in U-Boot itself. But if
>> >>>> you look at things in tools/ they include stdlib.h. With this header
>> >>>> available, we can more easily compile external code into U-Boot.
>> >>>
>> >>>
>> >>> So is it intended as fallback if the host doesn't have a stdlib.h?
>> >>
>> >> Not really, more that for things that expect that header (and
>> >> inttypes.h which was also added) they can get it without needing
>> >> special #ifdefs for U-Boot.
>> >>
>> >
>> >
>> > Sorry, I still don't get it.
>> > Could you explain user cases?
>>
>> If you have a C file which has '#include <stdlib.h> in it, because it
>> builds in another project as well as U-Boot, and needs mallloc(), then
>> you want to build it with U-Boot and include <common.h>, etc. then you
>> need U-Boot to have stdlib.h, or add a dummy stdlib.h in that project.
>> I am trying to make is easier for this case. This is a minor point,
>> but little fish-hooks can be frustrating.
>>
>
> I understand what you want to do,
> but I am not sure if this is a right decision.
>
> Mixing the same header name sometimes causes a mess.

That's true although I don't really see a big issue here.

IMO image.c and the like suffer from having two sets of headers - one
for building in U-Boot and one for building outside. I thought maybe
the solution was do have a section in common.h to deal with the
differences, but then when I looked more I wasn't sure it was an
improvement...

Regards,
Simon