init fails to compile for !CONFIG_FEATURE_KILL_REMOVED

[Ralf Friedl]

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.

Regards
Ralf Friedl