[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: init fails to compile for !CONFIG_FEATURE_KILL_REMOVED
From:       Rob Landley <rob () landley ! net>
Date:       2009-02-16 22:47:47
Message-ID: 200902161647.47532.rob () landley ! net
[Download RAW message or body]

On Monday 16 February 2009 04:23:24 Ralf Friedl wrote:
> Rob Landley wrote:
> > On Sunday 15 February 2009 06:30:12 Bernhard Reutner-Fischer wrote:
> >> On Sun, Feb 15, 2009 at 01:03:04PM +0100, Denys Vlasenko wrote:
> >>> On Sunday 15 February 2009 02:07, Rob Landley wrote:
> >>>>> This is the case when #if is better than if
> >>>>> (because #if would work, and if won't):
> >>>>
> >>>> Or, alternately, this is a case where the kconfig logic isn't doing
> >>>> what we want, and fixing it is one line:
> >>>>
> >>>> Index: scripts/kconfig/confdata.c
> >>>> ===================================================================
> >>>> --- scripts/kconfig/confdata.c	(revision 25316)
> >>>> +++ scripts/kconfig/confdata.c	(working copy)
> >>>> @@ -524,6 +524,7 @@
> >>>>  				}
> >>>>  			case S_INT:
> >>>>  				str = sym_get_string_value(sym);
> >>>> +				if (!*str) str="0";
> >>>>  				fprintf(out, "CONFIG_%s=%s\n", sym->name, str);
> >>>>  				if (out_h) {
> >>>>  					fprintf(out_h, "#define CONFIG_%s %s\n", sym->name, str);
> >>>
> >>> Applied, thanks!
> >>
> >> Shouldn't this better use the lower_bound -1 iff it's a range?
> >
> > My general theory for chosing 0 was:
> >
> > A) this only triggers when it's disabled by a dependency on another
> > boolean symbol anyway, so in theory the C code is going to be testing
> > that other symbol so the optimizer can remove it.  So it doesn't really
> > matter what actual value it has as long as it resolves to a valid integer
> > #define so it doesn't cause a syntax error before it gets optimized away.
> >
> > B) 0 is false in C.
>
> If the value of the symbol was empty before, it should be valid C to use
> "SYMBOL +0" or "SYMBOL -0". If SYMBOL is defined as an integer, this is
> parsed as an expression with the value of SYMBOL. If SYMBOL is defined
> as empty (not undefined), the "+0" or "-0" is parsed as an expression
> with value 0.

Except that doing that means we'd have to add guard code every use of the 
symbol, and just never having kconfig generate output for a symbol of type int 
that can't be used as an int makes more sense and means we don't have to be 
careful about using it.

The alternatives are:

A) adding special case code in the headers to individually redefine each 
integer symbol output by kconfig, ala "#define THINGY THINGY+0" (ick).

B) Modify kconfig to output all integer symbols as "VALUE+0", which is more 
complicated and less obvious than just fixing the actual bug directly.

Rob
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]