From: "Giovanni Bajo" <giovannibajo@libero.it>
To: "Bruce Korb" <bkorb@veritas.com>
Cc: <gcc-bugzilla@gcc.gnu.org>, "GCC-Patches" <gcc-patches@gcc.gnu.org>
Subject: Re: [Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
Date: Mon, 18 Oct 2004 13:38:00 -0000 [thread overview]
Message-ID: <03a001c4b517$932b4be0$f2422597@bagio> (raw)
In-Reply-To: <41734D28.A5607C6A@veritas.com>
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
prev parent reply other threads:[~2004-10-18 13:37 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20040630163127.16300.skunk@iskunk.org>
[not found] ` <20041016033011.24264.qmail@sourceware.org>
2004-10-18 6:23 ` Bruce Korb
2004-10-18 13:38 ` Giovanni Bajo [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='03a001c4b517$932b4be0$f2422597@bagio' \
--to=giovannibajo@libero.it \
--cc=bkorb@veritas.com \
--cc=gcc-bugzilla@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).