This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: The diff should be clean now...
- To: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- Subject: Re: The diff should be clean now...
- From: Bruce Korb <bkorb at sco dot COM>
- Date: Mon, 22 May 2000 09:22:08 -0700
- CC: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Organization: Santa Cruz Operations
- References: <200005211636.MAA21935@caip.rutgers.edu>
"Kaveh R. Ghazi" wrote:
> I've been trying for several days now and still cannot get
> clean diffs on _any_ platform I try. :-( I've tried solaris2.7,
> x86-linux, irix6.2 and aix4.1. None of them check cleanly, and worse
> still they all complain about different things. Some appear expected
> or harmless but I cannot say so for others.
:-( Please send me some diffs so I can have a look, too.
> It seems like you went ahead and installed most (but not all) of the
> test_text additions I sent you, so somehow you are getting clean diffs
> but I'm not. I don't know why.
It's really easy when you eyeball the diff and check in your own
version :-). The real question is why are my diffs appearing
different. I went to the trouble to sort the file list so that
compare order would not be part of the problem. Plus, I stripped
off the mod times. I am, however, aware that the SVR3 version of
diff is too brain damaged to use. Perhaps you are right and I
should add a shar archive of the expected output instead of
a "diff -cr" file. Heck, it might even be smaller :-).
> Another issue, the syntax and mechanism of the infrastructure appears
> to change every few days. It makes it hard especially because its so
> poorly documented. I have to redecipher everything too much. I
> understand its under development and that's the nature of it. But
> more communication or docs would help.
?? Not sure what you mean here. I recently added two new c_fix
procedures: format and wrap. In the process, I added "arguments"
to c_fix-es and Zack wanted to use that mechanism to bypass the need
for wrapper procedures around the char_macro_* fixes. He introduced
a bug that I fixed while making several new bugs :-( (I did
not have access to all the weird ways Sun permutes these IOCTL defines)....
> Another issue, there are still char_macro_def/char_macro_use bugs.
> I'll put together test_text entries for the failures. Hopefully we
> can work together to fix these.
Let's go back to Zack's original fix. I'm not sure how to cope
with:
+ test_text = "#define TIOCFOO BSD43__IOWR(T, 1)\n"
+ "#define TIOCFOO \\\\\n"
+ "BSD43__IOWR(T, 1) /* Some are multi-line */";
using regex constructs. (By the way, there are two too many
backslashes. You "only" need three.) Gosh, that is ugly stuff!
> Sorry if I sound a little frustrated right now.
You sound so because you are so because it is so frustrating :-).
> I still hope to
> continue helping with this mechanism since its so important to a
> platform like sunos4 which has many bogus headers. I'm just a little
> frazzled after being unable to get this to work.
OK, go ahead and make any changes you deem necessary.
If anything you do creates a problem or issue, we'll work
it out later. You're pretty careful and we work different
shifts :).