Re: [Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding

Re: [Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding

[Bruce Korb]

giovannibajo at libero dot it wrote:
> 
> ------- Additional Comments From giovannibajo at libero dot it  2004-10-16 03:30 -------
> CC'ing also Bruce because he's the fixincludes maintainer. Bruce, BTW, as a
> developer which digs for the first time in fixincludes, let me say that
> fixincludes/README is not very clear about how 'make check' is supposed to work.

I can only fix things about which I get feedback so it incrementally
gets better.  I'm sorry you found it difficult.

> Also, it does not explain if it is possible (and how) to use the test_text to
> verify the correctness of the fix. When I run 'make check' I don't understand
> if my new hack is being tested or not, and if it is correct or not.

"test-text" should contain one or more examples of broken text that
needs to be fixed.  "make check" will spin a file with that text in it
and run the "fixinc" program, then run a recursive "diff" between the
patched files and a set of example files.  Any differences are highlighted.
So, when you make a fix, you should pretty well understand how the
broken text ought to be transformed.  In the "make check", you ought
to see a diff that includes that new transform in the new output and
not in the sample output.

> 4.  Rebuild the compiler and check the header causing the issue.
>     Make sure it is now properly handled.  Add tests to the
>     "test_text" entry(ies) that validate your fix.  This will
>     help ensure that future fixes won't negate your work.

That means first, ensure the header you want fixed is fixed.
Then, incorporate the brokenness in the "text-text" field.
Then, ensure it is fixed in the sample output.
Then, add the fixed result into the baseline sample files.
Finally:

> If you are having some problem with a system header that is either
> broken by the manufacturer, or is broken by the fixinclude process,
> then you will need to alter or add information to the include fix
> definitions file, ``inclhack.def''.  Please also send relevant
> information to gcc-bugs@gcc.gnu.org, gcc-patches@gcc.gnu.org and,
> please, to me:  bkorb@gnu.org.

That means send me email if you are still having problems.

Regards, Bruce

Re: [Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding

[Giovanni Bajo]

Bruce Korb wrote:

>> I can only fix things about which I get feedback so it
>> incrementally gets better.  I'm sorry you found it difficult.

Sure, I did not want to sound offensive.


>> Also, it does not explain if it is possible (and how) to use the
>> test_text to
>> verify the correctness of the fix. When I run 'make check' I don't
>> understand
>> if my new hack is being tested or not, and if it is correct or not.
>
> "test-text" should contain one or more examples of broken text that
> needs to be fixed.  "make check" will spin a file with that text in it
> and run the "fixinc" program, then run a recursive "diff" between the
> patched files and a set of example files.  Any differences are
> highlighted.

I still do not understand. The diff is being performed between the patched file
and what example files? If I add a new fix, should I also put a patched
(correct) version in the set of example files (where are they)?


> So, when you make a fix, you should pretty well understand how the
> broken text ought to be transformed.  In the "make check", you ought
> to see a diff that includes that new transform in the new output and
> not in the sample output.

Now I am confused. I do not understand which of the following holds true:

- The diff shows what fixinclude did. It shows the different between the
original version (extracted from test-text) and the version that fixinclude
produced by applying your diff.
- The diff shows the mistakes of fixinclude, if any. It shows the different
between what fixinclude produced as output (by applying your fix to the
test-text) and what it is the expected result (which you have to put in a
different file -- where? how?).


>> 4.  Rebuild the compiler and check the header causing the issue.
>>     Make sure it is now properly handled.  Add tests to the
>>     "test_text" entry(ies) that validate your fix.  This will
>>     help ensure that future fixes won't negate your work.
>
> That means first, ensure the header you want fixed is fixed.
> Then, incorporate the brokenness in the "text-text" field.
> Then, ensure it is fixed in the sample output.
> Then, add the fixed result into the baseline sample files.

This process can be done if you have physical access to the host with the
broken header. In my case, I was developing a fixinclude for a broken header
for another system. I have the broken header as a file (attacched to the bug).
How can I test my fix in this situation?

BTW: "rebuild the compiler" is a tad too much as first quick test for a
fixinclude (e.g. check that the regulard expression does not have a typo or
so). Even assuming access to the host, would you please explain if there is a
quicker wasy to just run fixincludes without rebuilding everything? Of course,
a full bootstrap would be still required as a final check.


> That means send me email if you are still having problems.

Thanks
Giovanni Bajo