Hi Chris,
On Wed, 16 Jan 2013 17:23:58 +1300, Chris Packham
<judge.pack...@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.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
