On 7 January 2014 18:46, Tony Finch <d...@dotat.at> wrote: > Bernhard Reutner-Fischer <rep.dot....@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, _______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc