Hi Masahiro,
On 30 October 2014 01:53, Masahiro Yamada yamada.m@jp.panasonic.com wrote:
Hi Simon,
On Wed, 29 Oct 2014 19:43:26 -0600 Simon Glass sjg@chromium.org wrote:
Hi Masahiro,
On 29 October 2014 08:06, Masahiro YAMADA yamada.m@jp.panasonic.com wrote:
Hi Simon,
2014-10-29 3:24 GMT+09:00 Simon Glass sjg@chromium.org:
Hi,
On 28 October 2014 11:46, Jeroen Hofstee jeroen@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@jp.panasonic.com wrote: > > Hi Simon, > > > 2014-10-29 1:29 GMT+09:00 Simon Glass sjg@chromium.org: >> >> Hi Masahiro, >> >> On 28 October 2014 10:25, Masahiro YAMADA yamada.m@jp.panasonic.com >> wrote: >>> >>> Hi Gabe, Simon, >>> >>> >>> 2014-10-15 19:38 GMT+09:00 Simon Glass sjg@chromium.org: >>>> >>>> From: Gabe Black gabeblack@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@google.com >>>> Reviewed-by: Gabe Black gabeblack@chromium.org >>>> Tested-by: Gabe Black gabeblack@chromium.org >>>> Reviewed-by: Bill Richardson wfrichar@google.com >>>> Signed-off-by: Simon Glass sjg@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