[U-Boot] Function prototype conflicts with standalone apps

[Chris Packham]

On Thu, Jan 17, 2013 at 1:57 AM, Albert ARIBAUD
<albert.u.boot at aribaud.net>wrote:

> Hi Chris,
>
> On Wed, 16 Jan 2013 23:16:07 +1300, Chris Packham
> <judge.packham at gmail.com> wrote:
>
> > 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.
>
> Ok, so I misunderstood your objective -- my bad. It is not a problem of
> wanting to use a function which is part of the API; it's a problem of
> having to pull in non-API function declarations along with the API ones.
>
> I still think it's a bad idea to use a homonym of an existing U-Boot
> function, but at least you should not be prevented from doing so if
> the function is not actually in the API.
>
> But also I still dislike the solution you are suggestiong, because I
> think that the actual problem is not properly stated. Re-reading the
> common.h and exports.h header files, IIUC the actual problem is that
> exports.h depends on some types from common.h but common.h also defines
> some internal U-Boot functions. The problem is that common.h is needed
> for different and incompatible purposes: (public) API on the one hand,
> internal declarations on the other hand.
>
> Thus, I'd rather have common.h simply split into "a header file
> with basic types needed by both public API and internal code" and "a
> header file defining some internal U-Boot functions, possibly
> #including the shared basic types header file", with no conditional
> involved. New header file names to be chosen wisely.
>

So perhaps a variation on the patch I sent earlier in this thread. Instead
of moving definitions into export.h creating a new file (stddef.h ?) and
moving the things needed by export.h from common.h.

Something like this

---8<---