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.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)
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, > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot