update unifdef causing partial header generation and

[Bernhard Reutner-Fischer]

On 7 January 2014 18:46, Tony Finch <dot at dotat.at> wrote:
> Bernhard Reutner-Fischer <rep.dot.nop at gmail.com> wrote:
>>
>> Tony, when parsing defundefile there is an error in the linestate
>> machine, it seems. For me, several entries are "swallowed", i.e. not
>> parsed unless i conditionalize the fgets in skiphash on linestate.
>> When the state machine is confused and leaves defundefile,
>> processinout then starts with a confused state and throws away lines
>> erroneously (which is what the hunk cited above would attempt to
>> workaround after the fact, i guess).
>>
>> Please consider applying the 2 hunks in abovementioned commit c71f8bc
>> or let me know if that is either wrong or you need me to submit a
>> format patch.
>
> Thanks for the bug report! I will investigate. Do you have some example
> input that triggers this bug, that I could add to my test suite?

full reproducer w/ the correct data generated by the c71f8bc fix is here:
http://uclibc.org/~aldot/uClibc/unifdef-bug.tar.gz

before that fix we failed to record e.g. the __EXTRA_WARNINGS__ undef:

unifdef: addsym __UCLIBC_MALLOC_DEBUGGING__ undef
unifdef: parser line 223 state NO comment DIRTY line
unifdef: parser line 224 state NO comment START line
unifdef: #define
unifdef: addsym __WARNINGS__=
unifdef: parser line 225 state NO comment DIRTY line
unifdef: parser line 226 state NO comment START line
unifdef: #undef
unifdef: addsym __DOMULTI__ undef
unifdef: parser line 227 state NO comment DIRTY line
unifdef: parser line 228 state NO comment START line
unifdef: addsym _LIBC undef
unifdef: addsym __UCLIBC_GEN_LOCALE undef
unifdef: addsym __NO_CTYPE undef
unifdef: parser line 1 state C comment START line

also note how the var of the __WARNINGS__ sym is empty..

thanks,