[Buildroot] Qtopia4 Failure

Thiago A. Corrêa thiago.correa at gmail.com
Mon Sep 24 03:43:22 UTC 2007


   You are fixing newer, valid and good code in the name of legacy
compatibility with a flawed work around for legacy API. The simple
fact that there are more than one way around it doesn't make the patch
the better way. And I think we should strive for the better way to fix
things ;)

   Instead, I propose talk to the uclib guys (they are hopefully here,
if not, will join the uclib mailling list) to implement the legacy
support in a proper way.
   The OpenGroup is only recomending to use a macro. The only reason
for it is to avoid a function call, which might even be optimized out
by the compiler. The code that was implemented with the index() in
mind, expected it to be a function anyway, not a macro.

something like:
char * index (const char *string, int c)
{  return strchr( string, c ); }

I'm not proposing to drop the workaround, but keeping the macro does
break code as we are well aware. The above has no drawbacks that I can
think of, and beats patching good code ;)

Friendly Regards

On 9/24/07, Adam Hawes <adam at infocab.com.au> wrote:
> > A define claims the name index as if it were a keyword. It is a well
> > known issue.
> Yes, I am well aware of that.
> > How about change it to a function that wrapps the strchr()?
> > According to this:
> > http://www.opengroup.org/onlinepubs/000095399/functions/index.html
> > it used to be a function anyway.
> It's LEGACY.  To quote the open Group page you linked:
> "For maximum portability, it is recommended to replace the function call
> to index() as follows:
> #define index(a,b) strchr((a),(b))"
> The recommendation is to #define index when you need it in legacy code
> because it no longer exists in the standard library.  uClibc does this
> globally with a configuration option.
> > One other good solution would be to patch mplayer not to use this define.
> A good solution: yes.
> The only solution: no.  There is all sorts of other code that still uses
> legacy function calls.  It's not ideal but it's the way it is.  See my
> quote below.
> Quoting me:
> > > Fixing uClibc would be the sensible thing to do, and uClibc actually has
> > > a configuration option to turn off the legacy macros.  Turning them off,
> > > however, breaks compatibility with a few things (mplayer was the most
> > > recent one I found that wouldn't build with SUSv3 macros disabled).
> It is already possible to remove the macros from uClibc by turning off
> SUSv3_LEGACY_MACROS in the configuration file before you build it.  You
> don't need to patch uClibc.   Removing the macros may break more than
> just mplayer though.
> Regards,
> Adam

More information about the buildroot mailing list