[U-Boot] Function prototype conflicts with standalone apps

[Chris Packham]

Hi Albert,

On 01/16/2013 08:25 PM, Albert ARIBAUD (U-Boot) wrote:
> Hi Chris,
> 
> On Wed, 16 Jan 2013 17:23:58 +1300, Chris Packham
> <judge.packham at gmail.com> wrote:
> 
>> Hi,
>>
>> I've just run into something porting an existing out of tree board to
>> u-boot 2012.10 but I think it points to a generic issue for standalone
>> applications.
>>
>> Consider the following change
>>
>> diff --git a/examples/standalone/hello_world.c
>> b/examples/standalone/hello_world.c
>> index 067c390..d2e6a77 100644
>> --- a/examples/standalone/hello_world.c
>> +++ b/examples/standalone/hello_world.c
>> @@ -24,7 +24,7 @@
>>  #include <common.h>
>>  #include <exports.h>
>>
>> -int hello_world (int argc, char * const argv[])
>> +int net_init (int argc, char * const argv[])
>>  {
>>         int i;
>>
>> Because I'm not linking with the u-boot object file, I should be able to
>> use any function name I like in my application as long as it isn't one of
>> the functions in exports.h (at least in theory). Unfortunately I end up
>> with the following compiler error
>>
>>   hello_world.c:27: error: conflicting types for ‘net_init’
>>   uboot/include/net.h:489: error: previous declaration of ‘net_init’ was
>> here
>>   make[1]: *** [hello_world.o] Error 1
>>
>> If I replace #include <common.h> in my app with the first hunk of includes
>> from the top of common.h  then I can compile just fine.
>>
>> I was wondering if it made sense to people to have standalone applications
>> define something like __STANDALONE__ either via CPPFLAGS or in the source
>> itself and use the presence of that to exclude the majority of common.h
>> when used in standalone applications. Or alternatively move the required
>> bits to exports.h.
> 
> (long rant ahead. Short answer after end of rant)

Short response: Yep I can live with that by making some changes to my
standalone application. I just thought it might be cleaner if a minimal
set of definitions were provided.

> [RANT]
> 
> Code writers indeed have a right to name any function or other object
> any way they choose... within the constraints of the situation.
> 
> Some of these constraints stem from the tools -- you just cannot put an
> ampersand in a C object name, for instance -- and some stem from the
> 'agreement' entered into when using a library -- precisely, the
> agreement on the name and semantics of such and such object names.
> 
> Here, by including exports.h, you enter an agreement in which
> the object name 'net_init' receives a specific meaning. What you want
> is to benefit from the agreement without abiding by it.
> 
> Now this can be changed, technically, as most things are, and a new
> kind of agreement could be devised with fine-grain control on which
> object names would or would not be defined. The question is, *should*
> this be done?
> 
> Would you, analogously, suggest that Linux app developers be able to
> opt out of defining fopen() when they #include <stdio.h> because they
> feel they have a right to define 'char* fopen(float F)' in their code if
> they so please? And that it should be done so for just about any
> kernel-exported symbol? I suspect not.

Actually this is my point. The symbols aren't exported. They're just in
the header file. The kernel solution for this is using __KERNEL__ and
filtering the exported headers to remove the kernel internals not needed
by userland. If for some reason I did define a different fopen I'd get a
link error whether I included stdio or not.

> So why ask this from U-Boot?
> 
> [/RANT]
> 
> I personally will NAK such a suggestion. I don't see the point in
> adding complexity just to solve a naming conflict between a framework,
> de facto standard, name and a freely-modifiable application name. Just
> rename the application function -- that'll be all the better since that
> will also remove potential misunderstanding for readers of your code.
> 
>> Thanks,
>> Chris
> 
> Amicalement,
>