This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: pile of fixes for fixincl




Gerald Pfeifer wrote:
> 
> On Fri, 17 Dec 1999, Zack Weinberg wrote:
> > I have a number of further improvements in mind; who owns this code?
> 
> Bruce Korb <autogen@linuxbox.com>.
> 
> (BTW, he is also listed in our gcc/MAINTAINERS file.)

BTW, he also scans the gcc-patches and gcc-bugs every few days
for subject lines containing "fixinc".

Most of the fixes look fine, but I have a few comments.
Thank you, Zack, for your hard work.

Also, I had several patch failures, so I redid the patch, attached.
Please verify it and feel free to apply it.  If still undone,
I'll do it after Christmas.

Thanks again, Zack!

Regards,
	Bruce

===================================================================
Index: fixfixes.c
--- fixfixes.c  1999/11/01 18:14:50     1.4
+++ fixfixes.c  1999/12/17 11:56:04
@@ -312,9 +312,8 @@ FIX_PROC_HEAD( else_endif_label_fix )
                   break;
                 }
 
-              /*
-                FIXME:  if this is a C++ file, then a double slash comment
-                is allowed to follow the directive.  */
+              /* If this is a C++ file, fixtests will have already skipped
+                it, so we know this comment must be deleted.  */

-----------

Please, just remove the comment.  As you say, "this comment must be deleted."

===================================================================
Index: fixincl.c
--- fixincl.c   1999/11/29 14:33:50     1.21
+++ fixincl.c   1999/12/17 11:56:04
@@ -192,6 +193,8 @@ main (argc, argv)
 
   initialize ();
 
+  have_tty = isatty (fileno (stdout));
+
   /* Before anything else, ensure we can allocate our file name buffer. */
   file_name_buf = load_file_data (stdin);
 
@@ -1336,7 +1339,7 @@ process ()
 #ifdef DO_STATS
   process_ct++;
 #endif
-  if (VLEVEL( VERB_PROGRESS ))
+  if (VLEVEL( VERB_PROGRESS ) && have_tty)
     fprintf (stderr, "%6d %-50s   \r", data_map_size, pz_curr_file );

-----------

Q:  Is "isatty()" portable?  If so, then run it on STDERR, not stdout.
    stdout is _NEVER_ a tty.  It is always a pipe.

===================================================================

 I think this patch needs some more thinking.
 This is from SVR4.2 (With '#' replaced with '@').
 Perhaps we could do without the "/matherr/a" entries?
 Can we bypass the entire fix if someone was astute
 enough to have '#ifdef __cplusplus' anywhere in the file?
 
+We can definitely do without the "/matherr/a" entries.  They are
+there to cover the case where matherr is declared with no prototype
+-- extern int matherr(); -- but we don't need a fix then since there
+is no reference to struct exception.
+
+Bypassing on "#ifdef __cplusplus" is too optimistic, but I've stuck
+in a bypass for the comment in the glibc 2.1 header that indicates
+awareness of the problem.  Hmm.  Could we use a shell test that did
+cpp -D__cplusplus | grep "struct exception" ?

-----------

A shell test can do anything, of course.  All ya gotta do
is insert a configure-style script.  Yuck.  I think the
    bypass   = "We have a problem when using C++";
entry is adequate.  Thank you.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]