[U-Boot] Function prototype conflicts with standalone apps

[Albert ARIBAUD (U-Boot)]

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)

[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.

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,
-- 
Albert.