cpplib: Start moving switch handling to front ends

cpplib: Start moving switch handling to front ends

[Neil Booth]

This does all the -W and -f options that cpplib understands.  I don't
believe any are used by fix-header, so this is safe.  When I move
-D, -U etc. fix-header will need to be updated to handle them itself.

Bootstrapping x86 Linux, I'll apply it if successful.

Neil.

	* c-opts.c (cpp_opts): New.
	(COMMAND_LINE_OPTIONS): Add switches from cppinit.c.
	(c_common_decode_options): Handle cpplib switches.
	(c_common_init_options): Set cpp_opts.
	* cppinit.c (COMMAND_LINE_OPTIONS): Move some switches to c-opts.c.
	(cpp_handle_option): Similarly.

Index: c-opts.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/c-opts.c,v
retrieving revision 1.1
diff -u -p -r1.1 c-opts.c
--- c-opts.c	7 Aug 2002 18:32:07 -0000	1.1
+++ c-opts.c	7 Aug 2002 21:13:11 -0000
@@ -30,6 +30,8 @@ Software Foundation, 59 Temple Place - S
 #include "tree-inline.h"
 #include "diagnostic.h"
 
+static cpp_options *cpp_opts;
+
 static void missing_arg PARAMS ((size_t));
 static size_t parse_option PARAMS ((const char *, int));
 static void set_Wimplicit PARAMS ((int));
@@ -52,24 +54,42 @@ static void write_langs PARAMS ((char *,
 /* This is the list of all command line options, with the leading "-"
    removed.  It must be sorted in ASCII collating order.  All options
    beginning with "f" or "W" are implicitly assumed to take a "no-"
-   form; this form should not be listed.  If you don't want a "no-"
-   form, your handler should check and reject it.
+   form; this form should not be listed.  The variable "on" is true if
+   the positive form is given, otherwise it is false.  If you don't
+   want to allow a "no-" form, your handler should reject "on" being
+   false by returning zero.  See, for example, the handling of
+   -ftabstop=.
 
    If the user gives an option to a front end that doesn't support it,
    an error is output, mentioning which front ends the option is valid
    for.  If you don't want this, you must accept it for all front
-   ends, and test for the front end in the option handler.  */
+   ends, and test for the front end in the option handler.  See, for
+   example, the handling of -Wno-strict-prototypes for C++.
+
+   If you request an argument with CL_JOINED, CL_SEPARATE or their
+   combination CL_ARG, it is stored in the variable "arg", which is
+   guaranteed non-NULL.  It points to the argument either within the
+   argv[] vector or within one of its strings, and so the text is not
+   temporary and copies need not be made.
+
+   If you use the CL_SEPARATE flag (which is also in CL_ARG) be sure
+   to add an error message in missing_arg().  */
+
 #define COMMAND_LINE_OPTIONS						     \
   OPT("E",			CL_ALL,   OPT_E)			     \
   OPT("Wall",			CL_ALL,   OPT_Wall)			     \
   OPT("Wbad-function-cast",	CL_C,     OPT_Wbad_function_cast)	     \
   OPT("Wcast-qual",		CL_ALL,   OPT_Wcast_qual)		     \
   OPT("Wchar-subscripts",	CL_ALL,   OPT_Wchar_subscripts)		     \
+  OPT("Wcomment",		CL_ALL,   OPT_Wcomment)			     \
+  OPT("Wcomments",              CL_ALL,   OPT_Wcomments)		     \
   OPT("Wconversion",		CL_ALL,   OPT_Wconversion)		     \
   OPT("Wctor-dtor-privacy",	CL_CXX,   OPT_Wctor_dtor_privacy)	     \
   OPT("Wdeprecated",		CL_CXX,   OPT_Wdeprecated)		     \
   OPT("Wdiv-by-zero",		CL_C,     OPT_Wdiv_by_zero)		     \
   OPT("Weffc++",		CL_CXX,   OPT_Weffcxx)			     \
+  OPT("Wendif-labels",		CL_ALL,   OPT_Wendif_labels)		     \
+  OPT("Werror",                 CL_ALL,   OPT_Werror)			     \
   OPT("Werror-implicit-function-declaration",				     \
 	     			CL_C,     OPT_Werror_implicit_function_decl) \
   OPT("Wfloat-equal",		CL_ALL,   OPT_Wfloat_equal)		     \
@@ -83,6 +103,7 @@ static void write_langs PARAMS ((char *,
   OPT("Wimplicit",		CL_CXX,   OPT_Wimplicit)		     \
   OPT("Wimplicit-function-declaration",	CL_C, OPT_Wimplicit_function_decl)   \
   OPT("Wimplicit-int",		CL_C,	  OPT_Wimplicit_int)		     \
+  OPT("Wimport",                CL_ALL,   OPT_Wimport)			     \
   OPT("Wlong-long",		CL_ALL,   OPT_Wlong_long)		     \
   OPT("Wmain",			CL_C,     OPT_Wmain)			     \
   OPT("Wmissing-braces",	CL_ALL,   OPT_Wmissing_braces)		     \
@@ -109,8 +130,12 @@ static void write_langs PARAMS ((char *,
   OPT("Wsign-promo",		CL_CXX,   OPT_Wsign_promo)		     \
   OPT("Wstrict-prototypes",	CL_ALL,   OPT_Wstrict_prototypes)	     \
   OPT("Wsynth",			CL_CXX,   OPT_Wsynth)			     \
+  OPT("Wsystem-headers",	CL_ALL,   OPT_Wsystem_headers)		     \
   OPT("Wtraditional",		CL_C,     OPT_Wtraditional)		     \
+  OPT("Wtrigraphs",		CL_ALL,   OPT_Wtrigraphs)		     \
+  OPT("Wundef",			CL_ALL,   OPT_Wundef)			     \
   OPT("Wunknown-pragmas",	CL_ALL,   OPT_Wunknown_pragmas)		     \
+  OPT("Wunused-macros",		CL_ALL,   OPT_Wunused_macros)		     \
   OPT("Wwrite-strings",		CL_ALL,   OPT_Wwrite_strings)		     \
   OPT("ansi",			CL_ALL,   OPT_ansi)			     \
   OPT("faccess-control",	CL_CXX,   OPT_faccess_control)		     \
@@ -151,18 +176,22 @@ static void write_langs PARAMS ((char *,
   OPT("fnext-runtime",		CL_OBJC,  OPT_fnext_runtime)		     \
   OPT("fnonansi-builtins",	CL_CXX,   OPT_fnonansi_builtins)	     \
   OPT("fnonnull-objects",	CL_CXX,   OPT_fnonnull_objects)		     \
+  OPT("foperator-names",	CL_CXX,   OPT_foperator_names)		     \
   OPT("foptional-diags",	CL_CXX,   OPT_foptional_diags)		     \
   OPT("fpermissive",		CL_CXX,   OPT_fpermissive)		     \
+  OPT("fpreprocessed",		CL_ALL,   OPT_fpreprocessed)		     \
   OPT("frepo",			CL_CXX,   OPT_frepo)			     \
   OPT("frtti",			CL_CXX,   OPT_frtti)			     \
   OPT("fshort-double",		CL_ALL,   OPT_fshort_double)		     \
   OPT("fshort-enums",		CL_ALL,   OPT_fshort_enums)		     \
   OPT("fshort-wchar",		CL_ALL,   OPT_fshort_wchar)		     \
+  OPT("fshow-column",		CL_ALL,   OPT_fshow_column)		     \
   OPT("fsigned-bitfields",	CL_ALL,   OPT_fsigned_bitfields)	     \
   OPT("fsigned-char",		CL_ALL,   OPT_fsigned_char)		     \
   OPT("fsquangle",		CL_CXX,   OPT_fsquangle)		     \
   OPT("fstats",			CL_CXX,   OPT_fstats)			     \
   OPT("fstrict-prototype",	CL_CXX,   OPT_fstrict_prototype)	     \
+  OPT("ftabstop=",              CL_ALL | CL_JOINED,   OPT_ftabstop)	     \
   OPT("ftemplate-depth-",	CL_CXX | CL_JOINED, OPT_ftemplate_depth)     \
   OPT("fthis-is-variable",	CL_CXX,   OPT_fthis_is_variable)	     \
   OPT("funsigned-bitfields",	CL_ALL,   OPT_funsigned_bitfields)	     \
@@ -173,6 +202,8 @@ static void write_langs PARAMS ((char *,
   OPT("fweak",			CL_CXX,   OPT_fweak)			     \
   OPT("fxref",			CL_CXX,   OPT_fxref)			     \
   OPT("gen-decls",		CL_OBJC,  OPT_gen_decls)		     \
+  OPT("pedantic",		CL_ALL,   OPT_pedantic)			     \
+  OPT("pedantic-errors",	CL_ALL,   OPT_pedantic_errors)		     \
   OPT("print-objc-runtime-info", CL_OBJC, OPT_print_objc_runtime_info)	     \
   OPT("std=",			CL_ALL | CL_JOINED, OPT_std_bad)	     \
   OPT("std=c++98",		CL_CXX,	  OPT_std_cplusplus98)		     \
@@ -337,8 +368,10 @@ c_common_init_options (lang)
   c_language = lang;
   parse_in = cpp_create_reader (lang == clk_c || lang == clk_objective_c
 				? CLK_GNUC89 : CLK_GNUCXX);
+  cpp_opts = cpp_get_options (parse_in);
+
   if (lang == clk_objective_c)
-    cpp_get_options (parse_in)->objc = 1;
+    cpp_opts->objc = 1;
 
   flag_const_strings = (lang == clk_cplusplus);
   warn_pointer_arith = (lang == clk_cplusplus);
@@ -472,6 +505,10 @@ c_common_decode_option (argc, argv)
 	  warn_reorder = on;
 	  warn_nontemplate_friend = on;
 	}
+
+      cpp_opts->warn_trigraphs = on;
+      cpp_opts->warn_comments = on;
+      cpp_opts->warn_num_sign_change = on;
       break;
 
     case OPT_Wbad_function_cast:
@@ -486,6 +523,11 @@ c_common_decode_option (argc, argv)
       warn_char_subscripts = on;
       break;
 
+    case OPT_Wcomment:
+    case OPT_Wcomments:
+      cpp_opts->warn_comments = on;
+      break;
+
     case OPT_Wconversion:
       warn_conversion = on;
       break;
@@ -506,6 +548,14 @@ c_common_decode_option (argc, argv)
       warn_ecpp = on;
       break;
 
+    case OPT_Wendif_labels:
+      cpp_opts->warn_endif_labels = on;
+      break;
+
+    case OPT_Werror:
+      cpp_opts->warnings_are_errors = on;
+      break;
+
     case OPT_Werror_implicit_function_decl:
       if (!on)
 	{
@@ -559,6 +609,10 @@ c_common_decode_option (argc, argv)
       warn_implicit_int = on;
       break;
 
+    case OPT_Wimport:
+      cpp_opts->warn_import = on;
+      break;
+
     case OPT_Wlong_long:
       warn_long_long = on;
       break;
@@ -669,8 +723,21 @@ c_common_decode_option (argc, argv)
       warn_synth = on;
       break;
 
+    case OPT_Wsystem_headers:
+      cpp_opts->warn_system_headers = on;
+      break;
+
     case OPT_Wtraditional:
       warn_traditional = on;
+      cpp_opts->warn_traditional = on;
+      break;
+
+    case OPT_Wtrigraphs:
+      cpp_opts->warn_trigraphs = on;
+      break;
+
+    case OPT_Wundef:
+      cpp_opts->warn_undef = on;
       break;
 
     case OPT_Wunknown_pragmas:
@@ -679,6 +746,10 @@ c_common_decode_option (argc, argv)
       warn_unknown_pragmas = on * 2;
       break;
 
+    case OPT_Wunused_macros:
+      cpp_opts->warn_unused_macros = on;
+      break;
+
     case OPT_Wwrite_strings:
       if (c_language == clk_c || c_language == clk_objective_c)
 	flag_const_strings = on;
@@ -869,6 +940,10 @@ c_common_decode_option (argc, argv)
       flag_no_nonansi_builtin = !on;
       break;
 
+    case OPT_foperator_names:
+      cpp_opts->operator_names = on;
+      break;
+
     case OPT_foptional_diags:
       flag_optional_diags = on;
       break;
@@ -877,6 +952,10 @@ c_common_decode_option (argc, argv)
       flag_permissive = on;
       break;
 
+    case OPT_fpreprocessed:
+      cpp_opts->preprocessed = on;
+      break;
+
     case OPT_frepo:
       flag_use_repository = on;
       if (on)
@@ -887,10 +966,29 @@ c_common_decode_option (argc, argv)
       flag_rtti = on;
       break;
 
+    case OPT_fshow_column:
+      cpp_opts->show_column = on;
+      break;
+
     case OPT_fstats:
       flag_detailed_statistics = on;
       break;
 
+    case OPT_ftabstop:
+      /* Don't recognise -fno-tabstop=.  */
+      if (!on)
+	return 0;
+
+      /* It is documented that we silently ignore silly values.  */
+      if (*arg)
+	{
+	  char *endptr;
+	  long tabstop = strtol (arg, &endptr, 10);
+	  if (*endptr == '\0' && tabstop >= 1 && tabstop <= 100)
+	    cpp_opts->tabstop = tabstop;
+	}
+      break;
+
     case OPT_ftemplate_depth:
       max_tinst_depth = read_integral_parameter (arg, argv[0], 0);
       break;
@@ -909,6 +1007,17 @@ c_common_decode_option (argc, argv)
 
     case OPT_gen_decls:
       flag_gen_declaration = 1;
+      break;
+
+      /* We need to handle the -pedantic switches here, rather than in
+	 c_common_post_options, so that a subsequent -Wno-endif-labels
+	 is not overridden.  */
+    case OPT_pedantic_errors:
+      cpp_opts->pedantic_errors = 1;
+      /* fall through */
+    case OPT_pedantic:
+      cpp_opts->pedantic = 1;
+      cpp_opts->warn_endif_labels = 1;
       break;
 
     case OPT_print_objc_runtime_info:
Index: cppinit.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cppinit.c,v
retrieving revision 1.249
diff -u -p -r1.249 cppinit.c
--- cppinit.c	6 Aug 2002 20:35:41 -0000	1.249
+++ cppinit.c	7 Aug 2002 21:13:11 -0000
@@ -1156,34 +1156,7 @@ new_pending_directive (pend, text, handl
   DEF_OPT("MT",                       no_tgt, OPT_MT)                         \
   DEF_OPT("P",                        0,      OPT_P)                          \
   DEF_OPT("U",                        no_mac, OPT_U)                          \
-  DEF_OPT("Wall",                     0,      OPT_Wall)                       \
-  DEF_OPT("Wcomment",                 0,      OPT_Wcomment)                   \
-  DEF_OPT("Wcomments",                0,      OPT_Wcomments)                  \
-  DEF_OPT("Wendif-labels",            0,      OPT_Wendif_labels)              \
-  DEF_OPT("Werror",                   0,      OPT_Werror)                     \
-  DEF_OPT("Wimport",                  0,      OPT_Wimport)                    \
-  DEF_OPT("Wno-comment",              0,      OPT_Wno_comment)                \
-  DEF_OPT("Wno-comments",             0,      OPT_Wno_comments)               \
-  DEF_OPT("Wno-endif-labels",         0,      OPT_Wno_endif_labels)           \
-  DEF_OPT("Wno-error",                0,      OPT_Wno_error)                  \
-  DEF_OPT("Wno-import",               0,      OPT_Wno_import)                 \
-  DEF_OPT("Wno-system-headers",       0,      OPT_Wno_system_headers)         \
-  DEF_OPT("Wno-traditional",          0,      OPT_Wno_traditional)            \
-  DEF_OPT("Wno-trigraphs",            0,      OPT_Wno_trigraphs)              \
-  DEF_OPT("Wno-undef",                0,      OPT_Wno_undef)                  \
-  DEF_OPT("Wno-unused-macros",        0,      OPT_Wno_unused_macros)          \
-  DEF_OPT("Wsystem-headers",          0,      OPT_Wsystem_headers)            \
-  DEF_OPT("Wtraditional",             0,      OPT_Wtraditional)               \
-  DEF_OPT("Wtrigraphs",               0,      OPT_Wtrigraphs)                 \
-  DEF_OPT("Wundef",                   0,      OPT_Wundef)                     \
-  DEF_OPT("Wunused-macros",           0,      OPT_Wunused_macros)             \
   DEF_OPT("d",                        no_arg, OPT_d)                          \
-  DEF_OPT("fno-operator-names",       0,      OPT_fno_operator_names)         \
-  DEF_OPT("fno-preprocessed",         0,      OPT_fno_preprocessed)           \
-  DEF_OPT("fno-show-column",          0,      OPT_fno_show_column)            \
-  DEF_OPT("fpreprocessed",            0,      OPT_fpreprocessed)              \
-  DEF_OPT("fshow-column",             0,      OPT_fshow_column)               \
-  DEF_OPT("ftabstop=",                no_num, OPT_ftabstop)                   \
   DEF_OPT("h",                        0,      OPT_h)                          \
   DEF_OPT("idirafter",                no_dir, OPT_idirafter)                  \
   DEF_OPT("imacros",                  no_fil, OPT_imacros)                    \
@@ -1200,8 +1173,6 @@ new_pending_directive (pend, text, handl
   DEF_OPT("nostdinc",                 0,      OPT_nostdinc)                   \
   DEF_OPT("nostdinc++",               0,      OPT_nostdincplusplus)           \
   DEF_OPT("o",                        no_fil, OPT_o)                          \
-  DEF_OPT("pedantic",                 0,      OPT_pedantic)                   \
-  DEF_OPT("pedantic-errors",          0,      OPT_pedantic_errors)            \
   DEF_OPT("remap",                    0,      OPT_remap)                      \
   DEF_OPT("std=c++98",                0,      OPT_std_cplusplus98)            \
   DEF_OPT("std=c89",                  0,      OPT_std_c89)                    \
@@ -1363,31 +1334,6 @@ cpp_handle_option (pfile, argc, argv)
 	{
 	case N_OPTS: /* Shut GCC up.  */
 	  break;
-	case OPT_fno_operator_names:
-	  CPP_OPTION (pfile, operator_names) = 0;
-	  break;
-	case OPT_fpreprocessed:
-	  CPP_OPTION (pfile, preprocessed) = 1;
-	  break;
-	case OPT_fno_preprocessed:
-	  CPP_OPTION (pfile, preprocessed) = 0;
-	  break;
-	case OPT_fshow_column:
-	  CPP_OPTION (pfile, show_column) = 1;
-	  break;
-	case OPT_fno_show_column:
-	  CPP_OPTION (pfile, show_column) = 0;
-	  break;
-	case OPT_ftabstop:
-	  /* Silently ignore empty string, non-longs and silly values.  */
-	  if (arg[0] != '\0')
-	    {
-	      char *endptr;
-	      long tabstop = strtol (arg, &endptr, 10);
-	      if (*endptr == '\0' && tabstop >= 1 && tabstop <= 100)
-		CPP_OPTION (pfile, tabstop) = tabstop;
-	    }
-	  break;
 	case OPT_w:
 	  CPP_OPTION (pfile, inhibit_warnings) = 1;
 	  break;
@@ -1421,13 +1367,6 @@ cpp_handle_option (pfile, argc, argv)
 	case OPT_D:
 	  new_pending_directive (pend, arg, cpp_define);
 	  break;
-	case OPT_pedantic_errors:
-	  CPP_OPTION (pfile, pedantic_errors) = 1;
-	  /* fall through */
-	case OPT_pedantic:
-	  CPP_OPTION (pfile, pedantic) = 1;
-	  CPP_OPTION (pfile, warn_endif_labels) = 1;
-	  break;
 	case OPT_trigraphs:
 	  CPP_OPTION (pfile, trigraphs) = 1;
 	  break;
@@ -1666,77 +1605,6 @@ cpp_handle_option (pfile, argc, argv)
 	case OPT_idirafter:
 	  /* Add directory to end of path for includes.  */
 	  append_include_chain (pfile, xstrdup (arg), AFTER, 0);
-	  break;
-
-	case OPT_Wall:
-	  CPP_OPTION (pfile, warn_trigraphs) = 1;
-	  CPP_OPTION (pfile, warn_comments) = 1;
-	  CPP_OPTION (pfile, warn_num_sign_change) = 1;
-	  break;
-
-	case OPT_Wtraditional:
-	  CPP_OPTION (pfile, warn_traditional) = 1;
-	  break;
-	case OPT_Wno_traditional:
-	  CPP_OPTION (pfile, warn_traditional) = 0;
-	  break;
-
-	case OPT_Wtrigraphs:
-	  CPP_OPTION (pfile, warn_trigraphs) = 1;
-	  break;
-	case OPT_Wno_trigraphs:
-	  CPP_OPTION (pfile, warn_trigraphs) = 0;
-	  break;
-
-	case OPT_Wcomment:
-	case OPT_Wcomments:
-	  CPP_OPTION (pfile, warn_comments) = 1;
-	  break;
-	case OPT_Wno_comment:
-	case OPT_Wno_comments:
-	  CPP_OPTION (pfile, warn_comments) = 0;
-	  break;
-
-	case OPT_Wunused_macros:
-	  CPP_OPTION (pfile, warn_unused_macros) = 1;
-	  break;
-	case OPT_Wno_unused_macros:
-	  CPP_OPTION (pfile, warn_unused_macros) = 0;
-	  break;
-
-	case OPT_Wundef:
-	  CPP_OPTION (pfile, warn_undef) = 1;
-	  break;
-	case OPT_Wno_undef:
-	  CPP_OPTION (pfile, warn_undef) = 0;
-	  break;
-
-	case OPT_Wimport:
-	  CPP_OPTION (pfile, warn_import) = 1;
-	  break;
-	case OPT_Wno_import:
-	  CPP_OPTION (pfile, warn_import) = 0;
-	  break;
-
-	case OPT_Wendif_labels:
-	  CPP_OPTION (pfile, warn_endif_labels) = 1;
-	  break;
-	case OPT_Wno_endif_labels:
-	  CPP_OPTION (pfile, warn_endif_labels) = 0;
-	  break;
-
-	case OPT_Werror:
-	  CPP_OPTION (pfile, warnings_are_errors) = 1;
-	  break;
-	case OPT_Wno_error:
-	  CPP_OPTION (pfile, warnings_are_errors) = 0;
-	  break;
-
-	case OPT_Wsystem_headers:
-	  CPP_OPTION (pfile, warn_system_headers) = 1;
-	  break;
-	case OPT_Wno_system_headers:
-	  CPP_OPTION (pfile, warn_system_headers) = 0;
 	  break;
 	}
     }

Re: cpplib: Start moving switch handling to front ends

[Devang Patel]

On Wednesday, August 7, 2002, at 02:14  PM, Neil Booth wrote:

>
> +    case OPT_Wimport:
> +      cpp_opts->warn_import = on;
> +      break;

I was thinking about proposing a trivial patch to disable this
warning by default. Because #import is not deprecated and
widely used in darwin land. What is your opinion about this?

I am also preparing a patch to introduce one new warning flag,
-Wno-#warnings, to disable #warning messages. Is it a good idea?


-Devang

Re: cpplib: Start moving switch handling to front ends

[Zack Weinberg]

On Wed, Aug 07, 2002 at 04:58:11PM -0700, Devang Patel wrote:
> 
> On Wednesday, August 7, 2002, at 02:14  PM, Neil Booth wrote:
> 
> >
> >+    case OPT_Wimport:
> >+      cpp_opts->warn_import = on;
> >+      break;
> 
> I was thinking about proposing a trivial patch to disable this
> warning by default. Because #import is not deprecated and
> widely used in darwin land. What is your opinion about this?

"Darwin land" needs to stop using #import.

No, really.  The semantics of #import (and #pragma once) require that
the compiler be able to determine whether two include requests refer
to the same file, with 100% accuracy, for _correctness_.  This is
impossible without making unportable assumptions about file system
semantics, which cpplib does not do.

With #ifndef wrappers, the compiler can assume that two headers are
distinct if it can't prove that they are identical; if it is wrong, no
harm is done, because the #ifndef will prevent the code from being
re-processed anyway.

> I am also preparing a patch to introduce one new warning flag,
> -Wno-#warnings, to disable #warning messages. Is it a good idea?

I would prefer that effort go into a proper scheme to allow control
over _all_ warnings individually.  See, e.g.
http://gcc.gnu.org/ml/gcc/2000-06/msg00639.html for a possible
implementation.

zw

Re: cpplib: Start moving switch handling to front ends

[Devang Patel]

On Wednesday, August 7, 2002, at 05:36  PM, Zack Weinberg wrote:

> On Wed, Aug 07, 2002 at 04:58:11PM -0700, Devang Patel wrote:
>>
>> On Wednesday, August 7, 2002, at 02:14  PM, Neil Booth wrote:
>>
>>>
>>> +    case OPT_Wimport:
>>> +      cpp_opts->warn_import = on;
>>> +      break;
>>
>> I was thinking about proposing a trivial patch to disable this
>> warning by default. Because #import is not deprecated and
>> widely used in darwin land. What is your opinion about this?
>
> "Darwin land" needs to stop using #import.
>
> No, really.  The semantics of #import (and #pragma once) require that
> the compiler be able to determine whether two include requests refer
> to the same file, with 100% accuracy, for _correctness_.  This is
> impossible without making unportable assumptions about file system
> semantics, which cpplib does not do.
>
> With #ifndef wrappers, the compiler can assume that two headers are
> distinct if it can't prove that they are identical; if it is wrong, no
> harm is done, because the #ifndef will prevent the code from being
> re-processed anyway.

OK, OK. Personally, I have no opinion.
Once I said "Do not use #import, it is deprecated by GCC" in darwin land
and it spawned into huge thread. I do want to start it again here :-)

>> I am also preparing a patch to introduce one new warning flag,
>> -Wno-#warnings, to disable #warning messages. Is it a good idea?
>
> I would prefer that effort go into a proper scheme to allow control
> over _all_ warnings individually.  See, e.g.
> http://gcc.gnu.org/ml/gcc/2000-06/msg00639.html for a possible
> implementation.

It looks different than what I want.

[dpatel: gcc]$ cat foo.c

#warning Do not use this API after 4/1/2003
[dpatel: gcc]$ cc -c foo.c
foo.c:2:2: warning: #warning Do not use this API after 4/1/2003
[dpatel: gcc]$ cc -c foo.c -Wno-#warnings
[dpatel: gcc]$

This is useful in same way as -Wno-system-headers
Is it still a good idea?

Thank you,
-Devang

Re: cpplib: Start moving switch handling to front ends

[Neil Booth]

Zack Weinberg wrote:-

> No, really.  The semantics of #import (and #pragma once) require that
> the compiler be able to determine whether two include requests refer
> to the same file, with 100% accuracy, for _correctness_.  This is
> impossible without making unportable assumptions about file system
> semantics, which cpplib does not do.

We have them at the top of cppinit.c for duplicate directory checking.
Are you sure there's nothing we can do (granted, it might be a bit
awkward).  I think expecting the millions of lines of ObjC code to
suddenly stop using it is a bit much.

I'm all for banging #pragma once on the head for 3.4 though, so it
becomes an unknown pragma and treated like any other.

Neil.

Re: cpplib: Start moving switch handling to front ends

[Zack Weinberg]

On Thu, Aug 08, 2002 at 07:24:31AM +0100, Neil Booth wrote:
> Zack Weinberg wrote:-
> 
> > No, really.  The semantics of #import (and #pragma once) require that
> > the compiler be able to determine whether two include requests refer
> > to the same file, with 100% accuracy, for _correctness_.  This is
> > impossible without making unportable assumptions about file system
> > semantics, which cpplib does not do.
> 
> We have them at the top of cppinit.c for duplicate directory checking.
> Are you sure there's nothing we can do (granted, it might be a bit
> awkward).  I think expecting the millions of lines of ObjC code to
> suddenly stop using it is a bit much.

It would not be that hard to do the inode/dev check after opening the
file, we call fstat() anyway.  And that'd be a good idea.  (Have to figure
out a way to index the include cache on two different keys, though.)
It's just that, since inode numbers are not universally reliable --
hell, it's not even universally reliable _on Unix_, in the presence of
some file systems, and we are _not_ putting an fstatfs() blacklist in
there -- I don't want to encourage its use.

The other problem with #import is that the semantics are ill-defined
when someone uses both #import and #include to refer to (what turns
out to be) the same file.

> I'm all for banging #pragma once on the head for 3.4 though, so it
> becomes an unknown pragma and treated like any other.

Fine by me.

zw

Re: cpplib: Start moving switch handling to front ends

[Devang Patel]

On Thursday, August 8, 2002, at 12:11 AM, Zack Weinberg wrote:

> On Thu, Aug 08, 2002 at 07:24:31AM +0100, Neil Booth wrote:
>> Zack Weinberg wrote:-
>>
>>> No, really.  The semantics of #import (and #pragma once) require that
>>> the compiler be able to determine whether two include requests refer
>>> to the same file, with 100% accuracy, for _correctness_.  This is
>>> impossible without making unportable assumptions about file system
>>> semantics, which cpplib does not do.
>>
>> We have them at the top of cppinit.c for duplicate directory checking.
>> Are you sure there's nothing we can do (granted, it might be a bit
>> awkward).  I think expecting the millions of lines of ObjC code to
>> suddenly stop using it is a bit much.
>
> It would not be that hard to do the inode/dev check after opening the
> file, we call fstat() anyway.  And that'd be a good idea.  (Have to 
> figure
> out a way to index the include cache on two different keys, though.)

We do have local inode/dev check.  Here is the code snippet...

static ino_t new_inode;
static dev_t new_device;
static struct include_file *repl_file;

static int inode_finder PARAMS ((splay_tree_node, void *data));

static int
inode_finder (x, data)
      splay_tree_node x;
      void *data ATTRIBUTE_UNUSED;
{
   ino_t inode = 0;
   dev_t device = 0;

   if ((repl_file = (struct include_file *)x->value))
     {
       inode = repl_file->st.st_ino;
       device = repl_file->st.st_dev;
       if (inode == new_inode && device == new_device && DO_NOT_REREAD 
(repl_file))
         return 1;
     }
   return 0;
}

and inside open_file()....

   if (file->fd != -1 && fstat (file->fd, &file->st) == 0)
     {
       new_inode = file->st.st_ino;
       new_device = file->st.st_dev;
       if (splay_tree_foreach (pfile->all_include_files, inode_finder, 
0))
         {
           close (file->fd);
           file->fd  = -1;
           return repl_file;
         }

       if (!S_ISDIR (file->st.st_mode))
         return file;

       /* If it's a directory, we return null and continue the search
          as the file we're looking for may appear elsewhere in the
          search path.  */
       errno = ENOENT;
       close (file->fd);
       file->fd = -1;
     }

If interesting, I will prepare patch.

-Devang

Re: cpplib: Start moving switch handling to front ends

[Zack Weinberg]

On Thu, Aug 08, 2002 at 10:37:05AM -0700, Devang Patel wrote:
> >
> >It would not be that hard to do the inode/dev check after opening the
> >file, we call fstat() anyway.  And that'd be a good idea.  (Have to 
> >figure
> >out a way to index the include cache on two different keys, though.)
> 
> We do have local inode/dev check.  Here is the code snippet...
[...]

Yes, I am interested in seeing this cleaned up for submission.  You do
need to do some work first - for instance, those static variables must
go.

In some workloads the existing cpp spends ~10% of runtime in splay
tree lookups.  If we're dinking with this anyway, we might want to
think about a better data structure to use.

zw

Re: cpplib: Start moving switch handling to front ends

[Zack Weinberg]

On Thu, Aug 08, 2002 at 11:25:06AM -0700, Zack Weinberg wrote:
> On Thu, Aug 08, 2002 at 10:37:05AM -0700, Devang Patel wrote:
> > >
> > >It would not be that hard to do the inode/dev check after opening the
> > >file, we call fstat() anyway.  And that'd be a good idea.  (Have to 
> > >figure
> > >out a way to index the include cache on two different keys, though.)
> > 
> > We do have local inode/dev check.  Here is the code snippet...
> [...]
> 
> Yes, I am interested in seeing this cleaned up for submission.  You do
> need to do some work first - for instance, those static variables must
> go.

Oh, one more thing: you need to be using the INO_T_EQ and INO_T_COPY
macros from cppinit.c (move them to system.h).

zw

#import and indoes

[Devang Patel]

[-- Attachment #1: Type: text/plain, Size: 996 bytes --]


On Thursday, August 8, 2002, at 11:25  AM, Zack Weinberg wrote:

>
> On Thu, Aug 08, 2002 at 10:37:05AM -0700, Devang Patel wrote:
>>>
>>> It would not be that hard to do the inode/dev check after opening the
>>> file, we call fstat() anyway.  And that'd be a good idea.  (Have to
>>> figure
>>> out a way to index the include cache on two different keys, though.)
>>
>> We do have local inode/dev check.  Here is the code snippet...
> [...]
>
> Yes, I am interested in seeing this cleaned up for submission.  You do
> need to do some work first - for instance, those static variables must
> go.
>
> In some workloads the existing cpp spends ~10% of runtime in splay
> tree lookups.  If we're dinking with this anyway, we might want to
> think about a better data structure to use.

I will cleanup as you suggested and prepare patch.

Before I start looking around, do you have any suggestion about
some other existing data structure which I can use to replace splay 
tree ?

Thank you,
-Devang

[-- Attachment #2: Type: text/enriched, Size: 1068 bytes --]



On Thursday, August 8, 2002, at 11:25  AM, Zack Weinberg wrote:


<excerpt>

<fixed>On Thu, Aug 08, 2002 at 10:37:05AM -0700, Devang Patel wrote:

<excerpt><excerpt>

It would not be that hard to do the inode/dev check after opening the

file, we call fstat() anyway.  And that'd be a good idea.  (Have to 

figure

out a way to index the include cache on two different keys, though.)

</excerpt>

We do have local inode/dev check.  Here is the code snippet...

</excerpt>[...]


Yes, I am interested in seeing this cleaned up for submission.  You do

need to do some work first - for instance, those static variables must

go.


In some workloads the existing cpp spends ~10% of runtime in splay

tree lookups.  If we're dinking with this anyway, we might want to

think about a better data structure to use.

</fixed></excerpt><fixed>

I will cleanup as you suggested and prepare patch.

 

Before I start looking around, do you have any suggestion about 

some other existing data structure which I can use to replace splay
tree ?

</fixed>

Thank you,

-Devang

Re: #import and indoes

[Zack Weinberg]

On Thu, Aug 08, 2002 at 03:12:21PM -0700, Devang Patel wrote:
>  
> I will cleanup as you suggested and prepare patch. 

Thank you.

> Before I start looking around, do you have any suggestion about  
> some other existing data structure which I can use to replace splay 
> tree ? 

I would suggest the expandable hash tables (libiberty/hashtab.c) but
for its being difficult to index them on two different keys.  I
suppose you could have two tables pointing to the same record object.

zw

Re: cpplib: Start moving switch handling to front ends

[Stan Shebs]

Zack Weinberg wrote:

>"Darwin land" needs to stop using #import.
>
>No, really.  The semantics of #import (and #pragma once) require that
>the compiler be able to determine whether two include requests refer
>to the same file, with 100% accuracy, for _correctness_.  This is
>impossible without making unportable assumptions about file system
>semantics, which cpplib does not do.
>
Heh, we tried that argument with our users, but with literally thousands
of headers assuming #import or #pragma once, both internal and external
to Apple, plus an Objective-C book or two recommending the practice,
the response was, shall we say, "negative".  It was pretty clear they
were going to keep firing compiler folks until they found one who was
willing to un-deprecate #import. 1/2 :-)

In the users' defense, it must be said that #import has been working
well on a huge amount of code - in the 2 1/2 years that I've been at
Apple, we've seen dozens of ICEs for instance, but no failures of
#import to find the right file.  So it's not surprising that users
wonder why we're trying to fix something that doesn't seem broken.

Stan

Re: cpplib: Start moving switch handling to front ends

[Gabriel Dos Reis]

Stan Shebs <shebs@apple.com> writes:

[...]

| So it's not surprising that users
| wonder why we're trying to fix something that doesn't seem broken.

someone-jumping-in-the-middle-of-the-thread's question follows: Is GCC
trying to fix Apple's code? :-)

-- Gaby

Re: cpplib: Start moving switch handling to front ends

[Devang Patel]

On Thursday, August 8, 2002, at 10:39 AM, Gabriel Dos Reis wrote:

> Stan Shebs <shebs@apple.com> writes:
>
> [...]
>
> | So it's not surprising that users
> | wonder why we're trying to fix something that doesn't seem broken.
>
> someone-jumping-in-the-middle-of-the-thread's question follows: Is GCC
> trying to fix Apple's code? :-)

Millions of line of code uses #import without any problem and GCC is
deprecating it because of some reason (as Stan says not as
dangerous as anticipated) then it sounds like GCC is trying to fix
code by forcing users to replace millions, working fine so far, #imports
with #includes.

my thoughts,
-Devang

Re: cpplib: Start moving switch handling to front ends

[Zack Weinberg]

On Thu, Aug 08, 2002 at 10:34:11AM -0700, Stan Shebs wrote:
> Heh, we tried that argument with our users, but with literally thousands
> of headers assuming #import or #pragma once, both internal and external
> to Apple, plus an Objective-C book or two recommending the practice,
> the response was, shall we say, "negative".  It was pretty clear they
> were going to keep firing compiler folks until they found one who was
> willing to un-deprecate #import. 1/2 :-)
>
> In the users' defense, it must be said that #import has been working
> well on a huge amount of code - in the 2 1/2 years that I've been at
> Apple, we've seen dozens of ICEs for instance, but no failures of
> #import to find the right file.  So it's not surprising that users
> wonder why we're trying to fix something that doesn't seem broken.

Understood.

Apple's in a different boat from FSF GCC - you are only interested in
one platform, and you can make sure that ino/dev comparisons work
properly there.  I suppose I could live with a patch to disable that
warning for Darwin and Objective C only.  However, you could at least
update your own documentation to encourage use of #include and #ifndef
wrappers instead.  You could borrow the rationale from cpp.texi
(I wrote that text; you have my permission to use it)

There's also a concern about what it means to use both #include and
#import on the same file.  From the manual:

|    In the present implementation, a single use of `#import' will
| prevent the file from ever being read again, by either `#import' or
| `#include'.  You should not rely on this; do not use both `#import'
| and `#include' to refer to the same header file.

Is #pragma once in active use as well as #import?  Neil wanted to
ditch #pragma once.

zw

Re: cpplib: Start moving switch handling to front ends

[Neil Booth]

Zack Weinberg wrote:-

> |    In the present implementation, a single use of `#import' will
> | prevent the file from ever being read again, by either `#import' or
> | `#include'.  You should not rely on this; do not use both `#import'
> | and `#include' to refer to the same header file.
> 
> Is #pragma once in active use as well as #import?  Neil wanted to
> ditch #pragma once.

Hey! Not just me -- you're guilty as charged, too!

Neil.

Re: cpplib: Start moving switch handling to front ends

[Stan Shebs]

Zack Weinberg wrote:

>On Thu, Aug 08, 2002 at 10:34:11AM -0700, Stan Shebs wrote:
>
>>Heh, we tried that argument with our users, but with literally thousands
>>of headers assuming #import or #pragma once, both internal and external
>>to Apple, plus an Objective-C book or two recommending the practice,
>>the response was, shall we say, "negative".  It was pretty clear they
>>were going to keep firing compiler folks until they found one who was
>>willing to un-deprecate #import. 1/2 :-)
>>
>>In the users' defense, it must be said that #import has been working
>>well on a huge amount of code - in the 2 1/2 years that I've been at
>>Apple, we've seen dozens of ICEs for instance, but no failures of
>>#import to find the right file.  So it's not surprising that users
>>wonder why we're trying to fix something that doesn't seem broken.
>>
>
>Understood.
>
>Apple's in a different boat from FSF GCC - you are only interested in
>one platform, and you can make sure that ino/dev comparisons work
>properly there.  I suppose I could live with a patch to disable that
>warning for Darwin and Objective C only.  However, you could at least
>update your own documentation to encourage use of #include and #ifndef
>wrappers instead.  You could borrow the rationale from cpp.texi
>(I wrote that text; you have my permission to use it)
>
Even the encouragement of change was enough to get me threatened...
Many longtime NeXT developers believe passionately that #import is
the right way to go, and some even think that it should have been
adopted by the C standard instead of #include (it's not like
#include was mandated on the back of the tablets brought down from
Sinai, after all).

That attitude may change - GNUstep had this debate several months
ago, and decided to switch to #include/#ifndef I think - but I'm
figuring on having to support #import on Macs for several more
years.

>
>There's also a concern about what it means to use both #include and
>#import on the same file.  From the manual:
>
>|    In the present implementation, a single use of `#import' will
>| prevent the file from ever being read again, by either `#import' or
>| `#include'.  You should not rely on this; do not use both `#import'
>| and `#include' to refer to the same header file.
>
>Is #pragma once in active use as well as #import?  Neil wanted to
>ditch #pragma once.
>
I'll have to review our uses, but I think it's more of a historical
leftover than a matter of principle. :-)

Stan

Re: cpplib: Start moving switch handling to front ends

[Nicola Pero]

> >>Heh, we tried that argument with our users, but with literally thousands
> >>of headers assuming #import or #pragma once, both internal and external
> >>to Apple, plus an Objective-C book or two recommending the practice,
> >>the response was, shall we say, "negative".  It was pretty clear they
> >>were going to keep firing compiler folks until they found one who was
> >>willing to un-deprecate #import. 1/2 :-)
> >>
> >>In the users' defense, it must be said that #import has been working
> >>well on a huge amount of code - in the 2 1/2 years that I've been at
> >>Apple, we've seen dozens of ICEs for instance, but no failures of
> >>#import to find the right file.  So it's not surprising that users
> >>wonder why we're trying to fix something that doesn't seem broken.
> >>
> >
> >Understood.
> >
> >Apple's in a different boat from FSF GCC - you are only interested in
> >one platform, and you can make sure that ino/dev comparisons work
> >properly there.  I suppose I could live with a patch to disable that
> >warning for Darwin and Objective C only.  However, you could at least
> >update your own documentation to encourage use of #include and #ifndef
> >wrappers instead.  You could borrow the rationale from cpp.texi
> >(I wrote that text; you have my permission to use it)
> >
> Even the encouragement of change was enough to get me threatened...
> Many longtime NeXT developers believe passionately that #import is
> the right way to go, and some even think that it should have been
> adopted by the C standard instead of #include (it's not like
> #include was mandated on the back of the tablets brought down from
> Sinai, after all).
> 
> That attitude may change - GNUstep had this debate several months
> ago, and decided to switch to #include/#ifndef I think - but I'm
> figuring on having to support #import on Macs for several more
> years.

From time to time there is this flamewar #include vs #import in the
GNUstep mailing lists, but GNUstep has long been on the side of
#include/#ifndef and all GNUstep library headers are protected against
multiple inclusions.  GNUstep does suggest using #include in all the
documentation which produces.

But - but yes - users with a NeXT/Apple background are strongly in favour
of using #import though, usually protest when you tell them to use
#include, and GNUstep has to automatically disable gcc's warnings against
#import in the make system to prevent strong complains from them if the
compiler annoys them with warnings when they use #import. :-P



I think the opposition to #include raises because users don't like to
write 

#ifndef _FOUNDATION_NSOBJECT_H
#define _FOUNDATION_NSOBJECT_H
...
#endif /* _FOUNDATION_NSOBJECT_H */

in the header file being included, they normally complain that Java has
more high-level constructs to prevent multiple imports of a source file.

I often wondered if by simply replacing these three statements with a new,
higher-level statement at the beginning of file, we wouldn't make users
happy.

Something like (pardon the roughness of my example, details can be fixed,
maybe a #pragma or whatever preprocessor magic, I'm just sketching an
idea)

#header-name Foundation/NSObject.h

only one '#header-name' would be allowed in the file, and it must be the
first non-comment code in the file; when encountering this, the
preprocessor would behave as if the three statements include-protection
triad had been found - that is something like

#ifndef _INCLUDE_NAME_Foundation/NSObject.h_H_
#define _INCLUDE_NAME_Foundation/NSObject.h_H_

at the beginning, and

#endif /* _INCLUDE_NAME_Foundation/NSObject.h_H_ 

at the end of the file (the name of the preprocessor #define is built from
the provided #header-name).

Then, you could #include a file as you do in C, but to protect it against
multiple inclusions, a simple '#header-name' (or whatever preprocessor
directive might be appropriate) in the file to include would be enough
(and still it would be perfectly portable, and have all the benefits of a
traditional #ifnded/#define).

That would look a lot like a high-level construct, you can write it simply
and quickly, and might get the favour of users (even if in practice it
would be not at all different from the existing #include/#ifndef
machinery, just more simple and elegant to write).

It could be used in C as well, but there are many C compilers which
wouldn't support it so I guess it wouldn't be very popular; since the ObjC
compiler is pretty standardly the GCC one for everyone, if anyone agrees
on it and it is added, it would be basically an addition to the standard
language and quite portable.

Just my 2 cents for a way out of an otherwise un-solvable conflict. :-)

Re: cpplib: Start moving switch handling to front ends

[Zack Weinberg]

On Fri, Aug 09, 2002 at 08:37:16AM +0100, Nicola Pero wrote:
> I often wondered if by simply replacing these three statements with a new,
> higher-level statement at the beginning of file, we wouldn't make users
> happy.
> 
> Something like (pardon the roughness of my example, details can be fixed,
> maybe a #pragma or whatever preprocessor magic, I'm just sketching an
> idea)
> 
> #header-name Foundation/NSObject.h
> 
> only one '#header-name' would be allowed in the file, and it must be the
> first non-comment code in the file; when encountering this, the
> preprocessor would behave as if the three statements include-protection
> triad had been found - that is something like
> 
> #ifndef _INCLUDE_NAME_Foundation/NSObject.h_H_
> #define _INCLUDE_NAME_Foundation/NSObject.h_H_
> 
> at the beginning, and
> 
> #endif /* _INCLUDE_NAME_Foundation/NSObject.h_H_ 
> 
> at the end of the file (the name of the preprocessor #define is built from
> the provided #header-name).

This is an interesting idea.  It avoids the inode problem, since the
magic cookie is part of the file contents.  I'd suggest that the right
syntax is to give #pragma once an optional argument; then we need only
explain to users why this argument should be used.  The cookie should
be an identifier, for ease of parsing; you should be able to recycle
most of the existing include-guard code.

If you write the patch, and you can get buy-in from the ObjC community
to use this instead of #import, I'd be willing to consider it for FSF GCC.

zw

Re: cpplib: Start moving switch handling to front ends

[Nicola Pero]

> > I often wondered if by simply replacing these three statements with a new,
> > higher-level statement at the beginning of file, we wouldn't make users
> > happy.
> > 
> > Something like (pardon the roughness of my example, details can be fixed,
> > maybe a #pragma or whatever preprocessor magic, I'm just sketching an
> > idea)
> > 
> > #header-name Foundation/NSObject.h
> > 
> > only one '#header-name' would be allowed in the file, and it must be the
> > first non-comment code in the file; when encountering this, the
> > preprocessor would behave as if the three statements include-protection
> > triad had been found - that is something like
> > 
> > #ifndef _INCLUDE_NAME_Foundation/NSObject.h_H_
> > #define _INCLUDE_NAME_Foundation/NSObject.h_H_
> > 
> > at the beginning, and
> > 
> > #endif /* _INCLUDE_NAME_Foundation/NSObject.h_H_ 
> > 
> > at the end of the file (the name of the preprocessor #define is built from
> > the provided #header-name).
> 
> This is an interesting idea.  It avoids the inode problem, since the
> magic cookie is part of the file contents.

Precisely.


> I'd suggest that the right syntax is to give #pragma once an optional 
> argument; then we need only explain to users why this argument should 
> be used.

Ok - makes sense - I wouldn't mind some other syntax (even a dedicated
one) if it helps getting the support of Apple and core #import users :-)


> The cookie should be an identifier, for ease of parsing; you 
> should be able to recycle most of the existing include-guard code.
> 
> If you write the patch, and you can get buy-in from the ObjC community
> to use this instead of #import, I'd be willing to consider it for FSF GCC.

Unfortunately I'm leaving tomorrow for two weeks (holidays :-) so I have
to leave the discussion at this point.

I'll be very happy to write a patch when I get back if the idea is still
around.

Support from the ObjC community to use such a thing instead of #import
probably would take time.

The fact that the new syntax is widely available on newer GCCs would help;
maybe - if there is agreement that it's a good idea - we could start
providing the feature in the compiler, and start spreading the word that
you can use that now instead of #import.

I can investigate the feelings of the GNU ObjC community - which might
well be positive - they usually are with anything technically sound - and
GNUstep might start spreading the word :-) but if Apple goes consistently
against it, it's always going to be a hopeless battle for both fields,
like #include vs #import.

We can tell users to do #include <Foundation/Foundation.h>, we can write
that in all the doc, the examples, the mailing lists and whatever - but if
that makes their code impossible to port to Apple MacOSX because Apple
MacOSX headers are not protected against multiple inclusions (via #ifdefs
or via a new #pragma once xxx or some other mean inside the file itself)
and can only be included via #import (which is what it happens now), of
course users will think that #import <Foundation/Foundation.h> is more
portable than #include, since it works on both GNUstep and OSX, and they
will use #import - as they do now.  And there is little we can say against
such an argument.

So maybe a basic requirement for this thing to work and be accepted
largely by the ObjC programmers community is that all the major ObjC
parties/vendors agree it would be a good thing :-)

Re: cpplib: Start moving switch handling to front ends

[Stan Shebs]

Nicola Pero wrote:

>
>Something like (pardon the roughness of my example, details can be fixed,
>maybe a #pragma or whatever preprocessor magic, I'm just sketching an
>idea)
>
>#header-name Foundation/NSObject.h
>
>only one '#header-name' would be allowed in the file, and it must be the
>first non-comment code in the file; when encountering this, the
>preprocessor would behave as if the three statements include-protection
>triad had been found - that is something like
>
>#ifndef _INCLUDE_NAME_Foundation/NSObject.h_H_
>#define _INCLUDE_NAME_Foundation/NSObject.h_H_
>
>at the beginning, and
>
>#endif /* _INCLUDE_NAME_Foundation/NSObject.h_H_ 
>
>at the end of the file (the name of the preprocessor #define is built from
>the provided #header-name).
>
Interesting idea... I guess I'm not very keen on it, because it's yet 
another
mechanism to support, and there's not much incentive to change the
existing uses of #import in large bodies of source.

The hardcore advocates of #import defend it on philosophical grounds
rather than pragmatic ones, because #ifndef isn't really that hard to add
to source files.  So either we argue philosophy, or wait for the advocates
to die or retire. :-)

Stan

Re: cpplib: Start moving switch handling to front ends

[Russ Allbery]

Zack Weinberg <zack@codesourcery.com> writes:

> Apple's in a different boat from FSF GCC - you are only interested in
> one platform, and you can make sure that ino/dev comparisons work
> properly there.  I suppose I could live with a patch to disable that
> warning for Darwin and Objective C only.  However, you could at least
> update your own documentation to encourage use of #include and #ifndef
> wrappers instead.  You could borrow the rationale from cpp.texi (I wrote
> that text; you have my permission to use it)

I'm curious whether #import works correctly under AFS, for which there is
a client for MacOS X and which is used widely at educational institutions.
IIRC, inodes are per-volume in AFS, and it's therefore possible for a
header in a different volume to end up with the same inode and device
number as another header.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>

Re: cpplib: Start moving switch handling to front ends

[Hans-Peter Nilsson]

On Wed, 7 Aug 2002, Devang Patel wrote:
> I am also preparing a patch to introduce one new warning flag,
> -Wno-#warnings, to disable #warning messages. Is it a good idea?

Don't use '#' in the name.  That'd require quoting in a shell.
(Perhaps -Wno-hashwarnings?)

brgds, H-P

Re: cpplib: Start moving switch handling to front ends

[Devang Patel]

On Thursday, August 8, 2002, at 03:57 AM, Hans-Peter Nilsson wrote:

> On Wed, 7 Aug 2002, Devang Patel wrote:
>> I am also preparing a patch to introduce one new warning flag,
>> -Wno-#warnings, to disable #warning messages. Is it a good idea?
>
> Don't use '#' in the name.  That'd require quoting in a shell.
> (Perhaps -Wno-hashwarnings?)

I do not care about the name,  but instead of forcing current users
(darwin uses bash and/or tcsh as default shell) to change, it would
be nice if new user uses proper quoting.

Usually people hate to change makefiles for new compiler to just
rename command line option.

Personally I do not have hard opinion about this, but I have not seen
any guide-lines about use of special chars like '#' in warning names.

If everybody thinks, it is not OK then I will change it to 
-Wno-pound-warnings.

my thoughts,
-Devang

Re: cpplib: Start moving switch handling to front ends

[Gabriel Dos Reis]

Devang Patel <dpatel@apple.com> writes:

| If everybody thinks, it is not OK then I will change it to 
| -Wno-pound-warnings.

This, I think, would be less controversial.

-- Gaby

Re: cpplib: Start moving switch handling to front ends

[Neil Booth]

Gabriel Dos Reis wrote:-

> Devang Patel <dpatel@apple.com> writes:
> 
> | If everybody thinks, it is not OK then I will change it to 
> | -Wno-pound-warnings.
> 
> This, I think, would be less controversial.

I'm with Zack on this: I'm not a fan of these endless switches to
fine-tune the warnings.  Someone should come up with a plan to
solve the problem once and for all.

Neil.

Re: cpplib: Start moving switch handling to front ends

[Gabriel Dos Reis]

Neil Booth <neil@daikokuya.co.uk> writes:

| Gabriel Dos Reis wrote:-
| 
| > Devang Patel <dpatel@apple.com> writes:
| > 
| > | If everybody thinks, it is not OK then I will change it to 
| > | -Wno-pound-warnings.
| > 
| > This, I think, would be less controversial.
| 
| I'm with Zack on this: I'm not a fan of these endless switches to
| fine-tune the warnings.

I'm not suggesting that the switch should be added.  I'm just observing
that between "-Wno-#warning" and "-Wno-pound-warning", the latter
would be less controversial (especially given the quoting issue).

I didn't intend to choose a camp at this (late) time of the thread :-p

-- Gaby

Re: cpplib: Start moving switch handling to front ends

[Devang Patel]

On Thursday, August 8, 2002, at 10:49 AM, Neil Booth wrote:

> Gabriel Dos Reis wrote:-
>
>> Devang Patel <dpatel@apple.com> writes:
>>
>> | If everybody thinks, it is not OK then I will change it to
>> | -Wno-pound-warnings.
>>
>> This, I think, would be less controversial.

But, it will controversial for me on another list :-)

> I'm with Zack on this: I'm not a fan of these endless switches to
> fine-tune the warnings.  Someone should come up with a plan to
> solve the problem once and for all.

We will have to decide internally here, whether we want to
add another warning switch in FSF with different name than
local one.  Because, it would still mean we will have
one local patch to take care of (and original intention to
add this in FSF is to get rid of that patch)

Thanks,
-Devang

Re: cpplib: Start moving switch handling to front ends

[Stan Shebs]

Neil Booth wrote:

>Gabriel Dos Reis wrote:-
>
>Devang Patel <dpatel@apple.com> writes:
>
>| If everybody thinks, it is not OK then I will change it to 
>| -Wno-pound-warnings.
>
>This, I think, would be less controversial.
>
>
>I'm with Zack on this: I'm not a fan of these endless switches to
>fine-tune the warnings.  Someone should come up with a plan to
>solve the problem once and for all.
>
I agree, although the old proposal is distasteful to me, in that it
takes details of message phrasing and glues them into users' sources.

If we're willing to touch the warnings in GCC, we could add an
official name to each one that we want to control, so for instance
you would say

  warning ("comparison-always-true",
    "comparison is always true due to limited range of data type");

and that would automatically create -Wcomparison-always-true and
add to a warning control pragma.  Although the names do add to the
code, warnings-conscious users need well-defined terminology to talk
with each other about which warnings they're interested in.  Explicit
names also allow us to use the same name if the exigencies of coding
require the use to multiple warning() calls for a single kind of
warning.

Stan

Re: cpplib: Start moving switch handling to front ends

[Neil Booth]

Stan Shebs wrote:-

> I agree, although the old proposal is distasteful to me, in that it
> takes details of message phrasing and glues them into users' sources.
> 
> If we're willing to touch the warnings in GCC, we could add an
> official name to each one that we want to control, so for instance
> you would say
> 
>  warning ("comparison-always-true",
>    "comparison is always true due to limited range of data type");
> 
> and that would automatically create -Wcomparison-always-true and
> add to a warning control pragma.  Although the names do add to the
> code, warnings-conscious users need well-defined terminology to talk
> with each other about which warnings they're interested in.  Explicit
> names also allow us to use the same name if the exigencies of coding
> require the use to multiple warning() calls for a single kind of
> warning.

Hmm, OK, interesting.  But how is this better than just numbering
each warning?

Neil.

Re: cpplib: Start moving switch handling to front ends

[Gabriel Dos Reis]

Neil Booth <neil@daikokuya.co.uk> writes:

| Hmm, OK, interesting.  But how is this better than just numbering
| each warning?

As a human, I prefer self-explanatory words over numbers (even though
I'm educated as a mathematician).  Computers are very good at numbers,
I'm not :-) 

-- Gaby

Re: cpplib: Start moving switch handling to front ends

[Theodore Papadopoulo]

Stan Shebs wrote:-

> I agree, although the old proposal is distasteful to me, in that it
> takes details of message phrasing and glues them into users' sources.
> 
> If we're willing to touch the warnings in GCC, we could add an
> official name to each one that we want to control, so for instance
> you would say
> 
>  warning ("comparison-always-true",
>    "comparison is always true due to limited range of data type");
> 
> and that would automatically create -Wcomparison-always-true and
> add to a warning control pragma.  Although the names do add to the
> code, warnings-conscious users need well-defined terminology to talk
> with each other about which warnings they're interested in.  Explicit
> names also allow us to use the same name if the exigencies of coding
> require the use to multiple warning() calls for a single kind of
> warning.

Just a user opinion.
I like the idea... However, I'll add one more level and attempt to 
group warnings into categories so that it would be easy to add/disable
sets of coherent warnings (eg include related, comparison related, 
math related, etc...). I'm not sure that it will be easy to find a 
categorisation that would please everyone, but that would still be a 
nice feature to have.

After all we are in an object oriented world... ;-)

	Theo.

--------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
 --------------------------------------------------------------------

Re: cpplib: Start moving switch handling to front ends

[Paul Koning]

>>>>> "Neil" == Neil Booth <neil@daikokuya.co.uk> writes:

 Neil> Stan Shebs wrote:-
 >> If we're willing to touch the warnings in GCC, we could add an
 >> official name to each one that we want to control, so for instance
 >> you would say
 >> 
 >> warning ("comparison-always-true", "comparison is always true due
 >> to limited range of data type");
 >> 
 >> and that would automatically create -Wcomparison-always-true and
 >> add to a warning control pragma.  Although the names do add to the
 >> code, warnings-conscious users need well-defined terminology to
 >> talk with each other about which warnings they're interested in.
 >> Explicit names also allow us to use the same name if the
 >> exigencies of coding require the use to multiple warning() calls
 >> for a single kind of warning.

 Neil> Hmm, OK, interesting.  But how is this better than just
 Neil> numbering each warning?

I don't think it makes much difference.  Either way, the
identification of the warning needs to be (a) documented in a complete
list of warnings, (b) fixed for all time.

     paul

Re: cpplib: Start moving switch handling to front ends

[Mark D. Baushke]

Neil Booth <neil@daikokuya.co.uk> writes:
> 
> Stan Shebs wrote:-
> 
> > If we're willing to touch the warnings in GCC, we could add an
> > official name to each one that we want to control, so for instance
> > you would say
> > 
> >  warning ("comparison-always-true",
> >    "comparison is always true due to limited range of data type");
> > 
> > and that would automatically create -Wcomparison-always-true and
> > add to a warning control pragma.  Although the names do add to the
> > code, warnings-conscious users need well-defined terminology to talk
> > with each other about which warnings they're interested in.  Explicit
> > names also allow us to use the same name if the exigencies of coding
> > require the use to multiple warning() calls for a single kind of
> > warning.
> 
> Hmm, OK, interesting.  But how is this better than just numbering
> each warning?

For myself, I like names better than numbers in warnings.

Part of the problem is the 'official' number space for GCC derivatives.
It may occur that one or more organizations (*BSD, Apple, Redhat, et al)
may have versions of GCC that contain local patches, including new
warnings that are not immediately merged into the gcc.gnu.org sources.
This skew is nasty for users of 'gcc' when the number space manages to
allocate more than one numeric warning to different constructs in the
code base. While names may also have this problem, they are less likely
to be in conflict than numbers.

I will also note that if there is to be a revision on how warnings work,
it might also be nice to adapt -Werror to allow levels of severity in
order to transition to new versions of the compiler. If you have just
the old '-Werror', then any warning the compiler generates should error
out. However, it might be nice to find some way let 'new' warnings that
have been added to the compiler since the previous release to be less
fatal to the compilation, but still let the user know that the warning
needs to be fixed eventually... Or maybe we need a syntax to make
particular 'warnings' really be 'errors' like

   '-Werror=comparison-always-true,unused'
or '-Werror-comparison-always-true -Werror-unused' 
or '-Wcomparison-always-true -Wunused -Werror'

In other words, the -Werror switch implicitly add an 'error' property to
each -Wflag rather than having all warnings be errors.

Similarly, there should be a way to make a warning just a warning rather
than an error

   -Werror -Wunsigned -Wcomparison-always-true -Wno-error=uninitialized

would generate an error for 'unsigned' and 'comparison-always-true' but
just a plain warning for 'uninitialized' ...

	-- Mark

Re: cpplib: Start moving switch handling to front ends

[Fergus Henderson]

On 08-Aug-2002, Stan Shebs <shebs@apple.com> wrote:
> If we're willing to touch the warnings in GCC, we could add an
> official name to each one that we want to control, so for instance
> you would say
> 
>  warning ("comparison-always-true",
>    "comparison is always true due to limited range of data type");
> 
> and that would automatically create -Wcomparison-always-true and
> add to a warning control pragma.

I like this idea.

It might be nice to combine this with another option called say
"-Wprint-warning-names", which would ensure that compiler
diagnostics included the names of the warnings, e.g.

	foo.c:123: warning (comparison-always-true): comparison is always
	true due to limited range of data type

I also prefer warning names to warning numbers.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Re: cpplib: Start moving switch handling to front ends

[Stan Shebs]

Devang Patel wrote:

>
> On Thursday, August 8, 2002, at 03:57 AM, Hans-Peter Nilsson wrote:
>
>> On Wed, 7 Aug 2002, Devang Patel wrote:
>>
>>> I am also preparing a patch to introduce one new warning flag,
>>> -Wno-#warnings, to disable #warning messages. Is it a good idea?
>>
>>
>> Don't use '#' in the name.  That'd require quoting in a shell.
>> (Perhaps -Wno-hashwarnings?)
>
>
> I do not care about the name,  but instead of forcing current users
> (darwin uses bash and/or tcsh as default shell) to change, it would
> be nice if new user uses proper quoting.

The reason it hasn't been a problem for Apple is that PB wraps
doublequotes around all compiler arguments automatically.  If
this were to get out to people using regular make, there would be
a hue and cry about how their build got mangled (# is special to
make too, after all).

>
> Usually people hate to change makefiles for new compiler to just
> rename command line option.
>
> Personally I do not have hard opinion about this, but I have not seen
> any guide-lines about use of special chars like '#' in warning names.
>
> If everybody thinks, it is not OK then I will change it to 
> -Wno-pound-warnings.

"pound" is somewhat cultural - I think of the char as "sharp" (musical),
and H-P called it "hash".  If we do this, we should use terminology from
the language definition and call it -Wno-warning-directives.

Stan

Re: cpplib: Start moving switch handling to front ends

[Phil Edwards]

On Thu, Aug 08, 2002 at 10:59:02AM -0700, Stan Shebs wrote:
> > Personally I do not have hard opinion about this, but I have not seen
> > any guide-lines about use of special chars like '#' in warning names.
> >
> > If everybody thinks, it is not OK then I will change it to 
> > -Wno-pound-warnings.
> 
> "pound" is somewhat cultural - I think of the char as "sharp" (musical),
> and H-P called it "hash".  If we do this, we should use terminology from
> the language definition and call it -Wno-warning-directives.

-Wno-octothorpe-warnings, then, if you really want to be precise.  :-)


Phil

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002

Re: cpplib: Start moving switch handling to front ends

[Zack Weinberg]

On Thu, Aug 08, 2002 at 10:59:02AM -0700, Stan Shebs wrote:
> >If everybody thinks, it is not OK then I will change it to 
> >-Wno-pound-warnings.
> 
> "pound" is somewhat cultural - I think of the char as "sharp" (musical),
> and H-P called it "hash".  If we do this, we should use terminology from
> the language definition and call it -Wno-warning-directives.

I was considering suggesting -Wno-user-warnings, but I like your
spelling better.  And I do not have a problem with FSF GCC accepting
-Wno-#warnings as long as there is an alternate spelling that doesn't
use shell metacharacters, too.  (Neil is free to disagree.)  Note that
the Bourne shell spec says that # is only magic at the _beginning_ of
a token; not sure what csh does.

To backpedal a bit, it would be _nice_ if we had a general warning
control mechanism, but since we don't and won't get one in time for
3.3, I think that adding more -W options is okay.  It's certainly less
trouble than adding -f or -m options, which have a much bigger effect
on the compiler's behavior.

zw

Re: cpplib: Start moving switch handling to front ends

[Neil Booth]

Zack Weinberg wrote:-

> On Thu, Aug 08, 2002 at 10:59:02AM -0700, Stan Shebs wrote:
> > >If everybody thinks, it is not OK then I will change it to 
> > >-Wno-pound-warnings.
> > 
> > "pound" is somewhat cultural - I think of the char as "sharp" (musical),
> > and H-P called it "hash".  If we do this, we should use terminology from
> > the language definition and call it -Wno-warning-directives.
> 
> I was considering suggesting -Wno-user-warnings, but I like your
> spelling better.  And I do not have a problem with FSF GCC accepting
> -Wno-#warnings as long as there is an alternate spelling that doesn't
> use shell metacharacters, too.  (Neil is free to disagree.)  Note that

Fine by me.  I will, however, feel free to deprecate and eventually
remove the more trivial -W options that are rendered redundant when
we all finally agree on a generic suppression mechanism 8-)

Neil.

Re: cpplib: Start moving switch handling to front ends

[Richard Henderson]

On Thu, Aug 08, 2002 at 10:59:02AM -0700, Stan Shebs wrote:
> >If everybody thinks, it is not OK then I will change it to 
> >-Wno-pound-warnings.
> 
> "pound" is somewhat cultural - I think of the char as "sharp" (musical),
> and H-P called it "hash".  If we do this, we should use terminology from
> the language definition and call it -Wno-warning-directives.

I much prefer -Wno-warning-directives.


r~

PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Devang Patel]

On Thursday, August 8, 2002, at 02:00  PM, Richard Henderson wrote:

> On Thu, Aug 08, 2002 at 10:59:02AM -0700, Stan Shebs wrote:
>>> If everybody thinks, it is not OK then I will change it to
>>> -Wno-pound-warnings.
>>
>> "pound" is somewhat cultural - I think of the char as "sharp" 
>> (musical),
>> and H-P called it "hash".  If we do this, we should use terminology 
>> from
>> the language definition and call it -Wno-warning-directives.
>
> I much prefer -Wno-warning-directives.

Here is the patch.
OK to commit  ?

2002-12-08 Devang Patel <dpatel@apple.com>
         * c-opts.c (preprocess_file): Add new OPT_Wwarning-directives.
         (c_common_decode_option): Handle OPT_Wwarning_directives
         * cppinit.c (cpp_create_reader): Init warn_warning_directives
         * cpplib.c (do_warning): Add warn_warning_directives check.
         * cpplib.h (struct cpp_options): Add new item, 
warn_warning_directives.
         * doc/invoke.texi: Add information for -Wno-warning-directives.
testsuite:
         * gcc.dg/Wno-warning-directives.c: New test.



Index: gcc/c-opts.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/c-opts.c,v
retrieving revision 1.8
diff -c -3 -p -r1.8 c-opts.c
*** gcc/c-opts.c        12 Aug 2002 06:02:53 -0000      1.8
--- gcc/c-opts.c        12 Aug 2002 22:49:28 -0000
*************** static void preprocess_file PARAMS ((voi
*** 157,162 ****
--- 157,163 ----
     OPT("Wstrict-prototypes",   CL_ALL,   OPT_Wstrict_prototypes)       
      \
     OPT("Wsynth",                       CL_CXX,   OPT_Wsynth)           
              \
     OPT("Wsystem-headers",      CL_ALL,   OPT_Wsystem_headers)          
      \
+   OPT("Wwarning-directives",    CL_ALL,   OPT_Wwarning_directives)    
      \
     OPT("Wtraditional",         CL_C,     OPT_Wtraditional)             
      \
     OPT("Wtrigraphs",           CL_ALL,   OPT_Wtrigraphs)               
      \
     OPT("Wundef",                       CL_ALL,   OPT_Wundef)           
              \
*************** c_common_decode_option (argc, argv)
*** 820,825 ****
--- 821,830 ----

       case OPT_Wsystem_headers:
         cpp_opts->warn_system_headers = on;
+       break;
+
+     case OPT_Wwarning_directives:
+       cpp_opts->warn_warning_directives = on;
         break;

       case OPT_Wtraditional:
Index: gcc/cppinit.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/cppinit.c,v
retrieving revision 1.256
diff -c -3 -p -r1.256 cppinit.c
*** gcc/cppinit.c       12 Aug 2002 06:02:53 -0000      1.256
--- gcc/cppinit.c       12 Aug 2002 22:49:28 -0000
*************** cpp_create_reader (lang)
*** 471,476 ****
--- 471,477 ----
     cpp_set_lang (pfile, lang);
     CPP_OPTION (pfile, warn_import) = 1;
     CPP_OPTION (pfile, warn_multichar) = 1;
+   CPP_OPTION (pfile, warn_warning_directives) = 1;
     CPP_OPTION (pfile, discard_comments) = 1;
     CPP_OPTION (pfile, discard_comments_in_macro_exp) = 1;
     CPP_OPTION (pfile, show_column) = 1;
Index: gcc/cpplib.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/cpplib.c,v
retrieving revision 1.320
diff -c -3 -p -r1.320 cpplib.c
*** gcc/cpplib.c        23 Jul 2002 22:57:44 -0000      1.320
--- gcc/cpplib.c        12 Aug 2002 22:49:28 -0000
*************** do_warning (pfile)
*** 953,959 ****
        cpp_reader *pfile;
   {
     /* We want #warning diagnostics to be emitted in system headers 
too.  */
!   do_diagnostic (pfile, DL_WARNING_SYSHDR, 1);
   }

   /* Report program identification.  */
--- 953,960 ----
        cpp_reader *pfile;
   {
     /* We want #warning diagnostics to be emitted in system headers 
too.  */
!   if (CPP_OPTION (pfile, warn_warning_directives))
!     do_diagnostic (pfile, DL_WARNING_SYSHDR, 1);
   }

   /* Report program identification.  */
Index: gcc/cpplib.h
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/cpplib.h,v
retrieving revision 1.232
diff -c -3 -p -r1.232 cpplib.h
*** gcc/cpplib.h        12 Aug 2002 06:02:53 -0000      1.232
--- gcc/cpplib.h        12 Aug 2002 22:49:28 -0000
*************** struct cpp_options
*** 405,410 ****
--- 405,413 ----

     /* Nonzero means __STDC__ should have the value 0 in system 
headers.  */
     unsigned char stdc_0_in_system_headers;
+
+   /* Zero means, do not emit #warning warnings.  */
+   unsigned char warn_warning_directives;
   };

   /* Call backs.  */
Index: gcc/doc/invoke.texi
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/doc/invoke.texi,v
retrieving revision 1.170
diff -c -3 -p -r1.170 invoke.texi
*** gcc/doc/invoke.texi 11 Aug 2002 09:47:47 -0000      1.170
--- gcc/doc/invoke.texi 12 Aug 2002 22:49:32 -0000
*************** in the following sections.
*** 227,233 ****
   -Wno-multichar  -Wno-format-extra-args  -Wno-format-y2k @gol
   -Wno-import  -Wnonnull  -Wpacked  -Wpadded @gol
   -Wparentheses  -Wpointer-arith  -Wredundant-decls @gol
! -Wreturn-type  -Wsequence-point  -Wshadow @gol
   -Wsign-compare  -Wswitch  -Wswitch-default -Wswitch-enum @gol
   -Wsystem-headers -Wtrigraphs  -Wundef  -Wuninitialized @gol
   -Wunknown-pragmas  -Wunreachable-code @gol
--- 227,233 ----
   -Wno-multichar  -Wno-format-extra-args  -Wno-format-y2k @gol
   -Wno-import  -Wnonnull  -Wpacked  -Wpadded @gol
   -Wparentheses  -Wpointer-arith  -Wredundant-decls @gol
! -Wreturn-type  -Wsequence-point  -Wshadow -Wno-warning-directives @gol
   -Wsign-compare  -Wswitch  -Wswitch-default -Wswitch-enum @gol
   -Wsystem-headers -Wtrigraphs  -Wundef  -Wuninitialized @gol
   -Wunknown-pragmas  -Wunreachable-code @gol
*************** Warn whenever an @samp{#else} or an @sam
*** 2436,2441 ****
--- 2436,2445 ----
   @opindex Wshadow
   Warn whenever a local variable shadows another local variable, 
parameter or
   global variable or whenever a built-in function is shadowed.
+
+ @item -Wno-warning-directives
+ @opindex Wno-warning-directives
+ Disable #warning messages.

   @item -Wlarger-than-@var{len}
   @opindex Wlarger-than

Index: Wno-warning-directives.c
===================================================================
RCS file: Wno-warning-directives.c
diff -N Wno-warning-directives.c
*** /dev/null   1 Jan 1970 00:00:00 -0000
--- Wno-warning-directives.c    12 Aug 2002 22:56:28 -0000
***************
*** 0 ****
--- 1,16 ----
+ /* Test for -Wno-warning-directives compiler option.
+    Copyright (C) 2002 Free Software Foundation Inc
+    Contributed by Devang Patel <dpatel@apple.com>
+ */
+
+ /* { dg-do compile } */
+ /* { dg-options -Wno-warning-directives } */
+
+
+ #warning Do not use this APIs /* { dg-bogus "Do not use this APIs" } 
*/
+
+ int main ()
+ {
+   return 0;
+ }
+

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Neil Booth]

Devang Patel wrote:-

> Here is the patch.
> OK to commit  ?

Could you remind me of the rationale for this switch again?

> *************** static void preprocess_file PARAMS ((voi
> *** 157,162 ****
> --- 157,163 ----
>     OPT("Wstrict-prototypes",   CL_ALL,   OPT_Wstrict_prototypes)       
>      \
>     OPT("Wsynth",                       CL_CXX,   OPT_Wsynth)           
>              \
>     OPT("Wsystem-headers",      CL_ALL,   OPT_Wsystem_headers)          
>      \
> +   OPT("Wwarning-directives",    CL_ALL,   OPT_Wwarning_directives)    
>      \
>     OPT("Wtraditional",         CL_C,     OPT_Wtraditional)             
>      \
>     OPT("Wtrigraphs",           CL_ALL,   OPT_Wtrigraphs)               
>      \
>     OPT("Wundef",                       CL_ALL,   OPT_Wundef)           

Have you tried this?  If it works, you're lucky, and it will break
in the future 8-)

Neil.

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Devang Patel]

On Monday, August 12, 2002, at 04:01  PM, Neil Booth wrote:

> Devang Patel wrote:-
>
>> Here is the patch.
>> OK to commit  ?
>
> Could you remind me of the rationale for this switch again?

It was a long thread. But just like we have an option to disable
warnings from system header, somebody may need an options to
disable #warning messages.

>
>> *************** static void preprocess_file PARAMS ((voi
>> *** 157,162 ****
>> --- 157,163 ----
>>     OPT("Wstrict-prototypes",   CL_ALL,   OPT_Wstrict_prototypes)
>>      \
>>     OPT("Wsynth",                       CL_CXX,   OPT_Wsynth)
>>              \
>>     OPT("Wsystem-headers",      CL_ALL,   OPT_Wsystem_headers)
>>      \
>> +   OPT("Wwarning-directives",    CL_ALL,   OPT_Wwarning_directives)
>>      \
>>     OPT("Wtraditional",         CL_C,     OPT_Wtraditional)
>>      \
>>     OPT("Wtrigraphs",           CL_ALL,   OPT_Wtrigraphs)
>>      \
>>     OPT("Wundef",                       CL_ALL,   OPT_Wundef)
>
> Have you tried this?  If it works, you're lucky, and it will break
> in the future 8-)

It works for me, but may be I am missing something obvious.
What am I doing wrong? It is hard to keep track of stuff since
you are moving so fast!

-Devang

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Daniel Jacobowitz]

On Mon, Aug 12, 2002 at 04:08:57PM -0700, Devang Patel wrote:
> 
> On Monday, August 12, 2002, at 04:01  PM, Neil Booth wrote:
> 
> >Devang Patel wrote:-
> >
> >>Here is the patch.
> >>OK to commit  ?
> >
> >Could you remind me of the rationale for this switch again?
> 
> It was a long thread. But just like we have an option to disable
> warnings from system header, somebody may need an options to
> disable #warning messages.
> 
> >
> >>*************** static void preprocess_file PARAMS ((voi
> >>*** 157,162 ****
> >>--- 157,163 ----
> >>    OPT("Wstrict-prototypes",   CL_ALL,   OPT_Wstrict_prototypes)
> >>     \
> >>    OPT("Wsynth",                       CL_CXX,   OPT_Wsynth)
> >>             \
> >>    OPT("Wsystem-headers",      CL_ALL,   OPT_Wsystem_headers)
> >>     \
> >>+   OPT("Wwarning-directives",    CL_ALL,   OPT_Wwarning_directives)
> >>     \
> >>    OPT("Wtraditional",         CL_C,     OPT_Wtraditional)
> >>     \
> >>    OPT("Wtrigraphs",           CL_ALL,   OPT_Wtrigraphs)
> >>     \
> >>    OPT("Wundef",                       CL_ALL,   OPT_Wundef)
> >
> >Have you tried this?  If it works, you're lucky, and it will break
> >in the future 8-)
> 
> It works for me, but may be I am missing something obvious.
> What am I doing wrong? It is hard to keep track of stuff since
> you are moving so fast!

At a guess, the list looks alphabetically sorted.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Richard Henderson]

> At a guess, the list looks alphabetically sorted.

Yes.  And a binary search applied, so it _must_ be sorted.
There is in fact a comment to that effect at the top of
the array declaration.


r~

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Joseph S. Myers]

On Mon, 12 Aug 2002, Richard Henderson wrote:

> > At a guess, the list looks alphabetically sorted.
> 
> Yes.  And a binary search applied, so it _must_ be sorted.
> There is in fact a comment to that effect at the top of
> the array declaration.

A --enable-checking test at startup that the array _is_ sorted would be a
good idea.  (I put various sanity tests on the attribute tables in
init_attributes; they don't need to be sorted but there are various other
ways they could be wrong that are tested there; the same principle applies
to any tables that could be edited in a way that's wrong but not
immediately obviously wrong.)

(I don't see the use of this warning option, though.  Also, the Texinfo
needs to use @code{} around #warning, and the specification isn't clear
about whether with this option you still get -pedantic warnings for
#warning being an extension.)

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Sanity check for switch array

[Neil Booth]

Joseph S. Myers wrote:-

> A --enable-checking test at startup that the array _is_ sorted would be a
> good idea.

I've applied this.

Neil.

	* c-opts.c (c_common_init_options): Check option array is
	sorted if checking enabled.

Index: c-opts.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/c-opts.c,v
retrieving revision 1.9
diff -u -p -r1.9 c-opts.c
--- c-opts.c	12 Aug 2002 22:44:29 -0000	1.9
+++ c-opts.c	13 Aug 2002 06:47:47 -0000
@@ -495,6 +495,14 @@ c_common_init_options (lang)
      runtime.  */
   qsort (cl_options, N_OPTS, sizeof (struct cl_option), opt_comp);
 #endif
+#if ENABLE_CHECKING
+  size_t i;
+
+  for (i = 1; i < N_OPTS; i++)
+    if (strcmp (cl_options[i - 1].opt_text, cl_options[i].opt_text) >= 0)
+      error ("options array incorrectly sorted: %s is before %s",
+	     cl_options[i - 1].opt_text, cl_options[i].opt_text);
+#endif
 
   c_language = lang;
   parse_in = cpp_create_reader (lang == clk_c ? CLK_GNUC89 : CLK_GNUCXX);

Re: Sanity check for switch array

[Richard Henderson]

On Tue, Aug 13, 2002 at 07:48:50AM +0100, Neil Booth wrote:
> Joseph S. Myers wrote:-
> 
> > A --enable-checking test at startup that the array _is_ sorted would be a
> > good idea.
> 
> I've applied this.
> 
> Neil.
> 
> 	* c-opts.c (c_common_init_options): Check option array is
> 	sorted if checking enabled.
> 
> Index: c-opts.c
> ===================================================================
> RCS file: /cvs/gcc/gcc/gcc/c-opts.c,v
> retrieving revision 1.9
> diff -u -p -r1.9 c-opts.c
> --- c-opts.c	12 Aug 2002 22:44:29 -0000	1.9
> +++ c-opts.c	13 Aug 2002 06:47:47 -0000
> @@ -495,6 +495,14 @@ c_common_init_options (lang)
>       runtime.  */
>    qsort (cl_options, N_OPTS, sizeof (struct cl_option), opt_comp);
>  #endif
> +#if ENABLE_CHECKING
> +  size_t i;

Fails to compile on non-ascii hosts.  Need extra braces.


r~

Re: Sanity check for switch array

[Neil Booth]

Richard Henderson wrote:-

> Fails to compile on non-ascii hosts.  Need extra braces.

Doh, of course.  I'll fix it.

Neil.

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Devang Patel]

On Monday, August 12, 2002, at 04:30  PM, Daniel Jacobowitz wrote:

>
> At a guess, the list looks alphabetically sorted.

Oops. Here is the revised patch.

-Devang

2002-12-08 Devang Patel <dpatel@apple.com>
         * c-opts.c (preprocess_file): Add new OPT_Wwarning-directives.
         (c_common_decode_option): Handle OPT_Wwarning_directives
         * cppinit.c (cpp_create_reader): Init warn_warning_directives
         * cpplib.c (do_warning): Add warn_warning_directives check.
         * cpplib.h (struct cpp_options): Add new item, 
warn_warning_directives.
         * doc/invoke.texi: Add information for -Wno-warning-directives.
testsuite:
         * gcc.dg/Wno-warning-directives.c: New test.

Index: c-opts.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/c-opts.c,v
retrieving revision 1.8
diff -c -3 -p -r1.8 c-opts.c
*** c-opts.c    12 Aug 2002 06:02:53 -0000      1.8
--- c-opts.c    12 Aug 2002 23:40:31 -0000
*************** static void preprocess_file PARAMS ((voi
*** 162,167 ****
--- 162,168 ----
     OPT("Wundef",                       CL_ALL,   OPT_Wundef)           
              \
     OPT("Wunknown-pragmas",     CL_ALL,   OPT_Wunknown_pragmas)         
      \
     OPT("Wunused-macros",               CL_ALL,   OPT_Wunused_macros)   
              \
+   OPT("Wwarning-directives",    CL_ALL,   OPT_Wwarning_directives)    
      \
     OPT("Wwrite-strings",               CL_ALL,   OPT_Wwrite_strings)   
              \
     OPT("ansi",                 CL_ALL,   OPT_ansi)                     
      \
     OPT("d",                      CL_ALL | CL_JOINED, OPT_d)            
      \
*************** c_common_decode_option (argc, argv)
*** 820,825 ****
--- 821,830 ----

       case OPT_Wsystem_headers:
         cpp_opts->warn_system_headers = on;
+       break;
+
+     case OPT_Wwarning_directives:
+       cpp_opts->warn_warning_directives = on;
         break;

       case OPT_Wtraditional:
Index: gcc/cppinit.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/cppinit.c,v
retrieving revision 1.256
diff -c -3 -p -r1.256 cppinit.c
*** gcc/cppinit.c       12 Aug 2002 06:02:53 -0000      1.256
--- gcc/cppinit.c       12 Aug 2002 22:49:28 -0000
*************** cpp_create_reader (lang)
*** 471,476 ****
--- 471,477 ----
     cpp_set_lang (pfile, lang);
     CPP_OPTION (pfile, warn_import) = 1;
     CPP_OPTION (pfile, warn_multichar) = 1;
+   CPP_OPTION (pfile, warn_warning_directives) = 1;
     CPP_OPTION (pfile, discard_comments) = 1;
     CPP_OPTION (pfile, discard_comments_in_macro_exp) = 1;
     CPP_OPTION (pfile, show_column) = 1;
Index: gcc/cpplib.c
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/cpplib.c,v
retrieving revision 1.320
diff -c -3 -p -r1.320 cpplib.c
*** gcc/cpplib.c        23 Jul 2002 22:57:44 -0000      1.320
--- gcc/cpplib.c        12 Aug 2002 22:49:28 -0000
*************** do_warning (pfile)
*** 953,959 ****
        cpp_reader *pfile;
   {
     /* We want #warning diagnostics to be emitted in system headers 
too.  */
!   do_diagnostic (pfile, DL_WARNING_SYSHDR, 1);
   }

   /* Report program identification.  */
--- 953,960 ----
        cpp_reader *pfile;
   {
     /* We want #warning diagnostics to be emitted in system headers 
too.  */
!   if (CPP_OPTION (pfile, warn_warning_directives))
!     do_diagnostic (pfile, DL_WARNING_SYSHDR, 1);
   }

   /* Report program identification.  */
Index: gcc/cpplib.h
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/cpplib.h,v
retrieving revision 1.232
diff -c -3 -p -r1.232 cpplib.h
*** gcc/cpplib.h        12 Aug 2002 06:02:53 -0000      1.232
--- gcc/cpplib.h        12 Aug 2002 22:49:28 -0000
*************** struct cpp_options
*** 405,410 ****
--- 405,413 ----

     /* Nonzero means __STDC__ should have the value 0 in system 
headers.  */
     unsigned char stdc_0_in_system_headers;
+
+   /* Zero means, do not emit #warning warnings.  */
+   unsigned char warn_warning_directives;
   };

   /* Call backs.  */
Index: gcc/doc/invoke.texi
===================================================================
RCS file: /cvsroot/gcc/gcc/gcc/doc/invoke.texi,v
retrieving revision 1.170
diff -c -3 -p -r1.170 invoke.texi
*** gcc/doc/invoke.texi 11 Aug 2002 09:47:47 -0000      1.170
--- gcc/doc/invoke.texi 12 Aug 2002 22:49:32 -0000
*************** in the following sections.
*** 227,233 ****
   -Wno-multichar  -Wno-format-extra-args  -Wno-format-y2k @gol
   -Wno-import  -Wnonnull  -Wpacked  -Wpadded @gol
   -Wparentheses  -Wpointer-arith  -Wredundant-decls @gol
! -Wreturn-type  -Wsequence-point  -Wshadow @gol
   -Wsign-compare  -Wswitch  -Wswitch-default -Wswitch-enum @gol
   -Wsystem-headers -Wtrigraphs  -Wundef  -Wuninitialized @gol
   -Wunknown-pragmas  -Wunreachable-code @gol
--- 227,233 ----
   -Wno-multichar  -Wno-format-extra-args  -Wno-format-y2k @gol
   -Wno-import  -Wnonnull  -Wpacked  -Wpadded @gol
   -Wparentheses  -Wpointer-arith  -Wredundant-decls @gol
! -Wreturn-type  -Wsequence-point  -Wshadow -Wno-warning-directives @gol
   -Wsign-compare  -Wswitch  -Wswitch-default -Wswitch-enum @gol
   -Wsystem-headers -Wtrigraphs  -Wundef  -Wuninitialized @gol
   -Wunknown-pragmas  -Wunreachable-code @gol
*************** Warn whenever an @samp{#else} or an @sam
*** 2436,2441 ****
--- 2436,2445 ----
   @opindex Wshadow
   Warn whenever a local variable shadows another local variable, 
parameter or
   global variable or whenever a built-in function is shadowed.
+
+ @item -Wno-warning-directives
+ @opindex Wno-warning-directives
+ Disable #warning messages.

   @item -Wlarger-than-@var{len}
   @opindex Wlarger-than

Index: Wno-warning-directives.c
===================================================================
RCS file: Wno-warning-directives.c
diff -N Wno-warning-directives.c
*** /dev/null   1 Jan 1970 00:00:00 -0000
--- Wno-warning-directives.c    12 Aug 2002 22:56:28 -0000
***************
*** 0 ****
--- 1,16 ----
+ /* Test for -Wno-warning-directives compiler option.
+    Copyright (C) 2002 Free Software Foundation Inc
+    Contributed by Devang Patel <dpatel@apple.com>
+ */
+
+ /* { dg-do compile } */
+ /* { dg-options -Wno-warning-directives } */
+
+
+ #warning Do not use this APIs /* { dg-bogus "Do not use this APIs" } 
*/
+
+ int main ()
+ {
+   return 0;
+ }
+

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Richard Henderson]

On Mon, Aug 12, 2002 at 04:08:57PM -0700, Devang Patel wrote:
> It was a long thread. But just like we have an option to disable
> warnings from system header, somebody may need an options to
> disable #warning messages.

I'm not particularly friendly to this option.

Warnings from the compiler are something over which you have less
control, whereas you have complete control over warning directives.

If the argument is that this warning comes from third-party header
files, the counter-argument is that the third party probably put
it in there for a reason, and that if you ignore the warning you
may well not understand the input constraints of the package.

If someone is going to go to this extreme to ignore warnings, IMO
they can bloody well turn them all off with "-w".

Can you give a better rationale than "someone sometime might like it"?


r~

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Devang Patel]

On Monday, August 12, 2002, at 04:42  PM, Richard Henderson wrote:

> On Mon, Aug 12, 2002 at 04:08:57PM -0700, Devang Patel wrote:
>> It was a long thread. But just like we have an option to disable
>> warnings from system header, somebody may need an options to
>> disable #warning messages.
>
> I'm not particularly friendly to this option.
>
> Warnings from the compiler are something over which you have less
> control, whereas you have complete control over warning directives.
>
> If the argument is that this warning comes from third-party header
> files, the counter-argument is that the third party probably put
> it in there for a reason, and that if you ignore the warning you
> may well not understand the input constraints of the package.
>

What if it is coming from system headers ?

> If someone is going to go to this extreme to ignore warnings, IMO
> they can bloody well turn them all off with "-w".

For a normal application developer, a warning generated by compiler
and message from warning directives from system header are same in the 
sense
that he does not have control over it. At the same time user does
not want to use -w and use -Werror to take care and fix his own
warnings.

User can use -Wno-system-headers to mask system header warnings in this
situation, but it does not cover #warning. Hence this new option.

-Devang

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Geoff Keating]

Devang Patel <dpatel@apple.com> writes:

> On Monday, August 12, 2002, at 04:42  PM, Richard Henderson wrote:
> 
> > On Mon, Aug 12, 2002 at 04:08:57PM -0700, Devang Patel wrote:
> >> It was a long thread. But just like we have an option to disable
> >> warnings from system header, somebody may need an options to
> >> disable #warning messages.
> >
> > I'm not particularly friendly to this option.
> >
> > Warnings from the compiler are something over which you have less
> > control, whereas you have complete control over warning directives.
> >
> > If the argument is that this warning comes from third-party header
> > files, the counter-argument is that the third party probably put
> > it in there for a reason, and that if you ignore the warning you
> > may well not understand the input constraints of the package.
> >
> 
> What if it is coming from system headers ?

... then presumably the system header file author put it in there for
a reason?

> > If someone is going to go to this extreme to ignore warnings, IMO
> > they can bloody well turn them all off with "-w".
> 
> For a normal application developer, a warning generated by compiler
> and message from warning directives from system header are same in the
> sense
> that he does not have control over it. At the same time user does
> not want to use -w and use -Werror to take care and fix his own
> warnings.
> 
> User can use -Wno-system-headers to mask system header warnings in this
> situation, but it does not cover #warning. Hence this new option.

Typically a #warning from a system header does indicate an error in
the use of that header.

I proposed more general solution to this sort of problem in
<http://gcc.gnu.org/ml/gcc/2000-06/msg00639.html>.  An extension to
this would allow the user to say "if any warning comes from this file,
it's an error", something like

#pragma gcc warn_error file __FILE__

That way, the programmer could indicate that particular files, which
she controls, ought to be warning-free, and let the rest of the world
go its own way.

(The programmer can then put the #pragma in header files, which
catches the common case where the headers generate no warnings when
the programmer uses them but do when other people use them.)

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Stan Shebs]

Geoff Keating wrote:

 >Typically a #warning from a system header does indicate an error in
 >the use of that header.
 >
That may be the use that you're familiar with, but that's certainly
not required by the specification of the construct.  People at Apple
regularly use this to apprise library clients of impending change,
perhaps something like "this will go away on 2002-10-01".  If you
have to rebuild tomorrow and your project requires -Werror, perhaps
because it's a security component, and the replacement for the soon-
to-be-retired API hasn't been put into the library yet, you need a way
to suppress the message after you've determined you can't do anything
about it today.

Stan

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Richard Henderson]

On Mon, Aug 12, 2002 at 06:03:10PM -0700, Stan Shebs wrote:
> That may be the use that you're familiar with, but that's certainly
> not required by the specification of the construct.  People at Apple
> regularly use this to apprise library clients of impending change,
> perhaps something like "this will go away on 2002-10-01".  If you
> have to rebuild tomorrow and your project requires -Werror, perhaps
> because it's a security component, and the replacement for the soon-
> to-be-retired API hasn't been put into the library yet, you need a way
> to suppress the message after you've determined you can't do anything
> about it today.

If the warning is added before the replacement API,
the library authors should be flogged.



r~

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Mark Mitchell]

--On Monday, August 12, 2002 06:03:10 PM -0700 Stan Shebs <shebs@apple.com> 
wrote:

> Geoff Keating wrote:
>
>  >Typically a #warning from a system header does indicate an error in
>  >the use of that header.
>  >
> That may be the use that you're familiar with, but that's certainly
> not required by the specification of the construct.

Nothing about the problems you're having are new, as I understand it.
In other words, nothing about the compiler's behavior changed recently,
right?

A little up-front experimentation with #warning/-Werror a while back
would have saved you (in the collective sense) a lot of grief. :-)

I think a note in the manual is a good idea to warn (#warn?) people
about this problem, but I do not see a good reason to change the
behavior of the compiler.

The fact that these problems are coming from system headers makes me
less sympathetic, not more; OS vendors ought to be extra-careful in
terms of making their headers palatable to compilers past, present,
and future.

Even less do I see reasons to add a new switch to change the behavior
of the compiler.  We simply must stop adding a new switch every time
the compiler doesn't behave the way we want; this constant splitting of
the proverbial baby by creating switches for me to use and switches
for you to use makes the compiler bigger and the manual fatter without
much benefit.

If the consensus turns out to be that we should ignore #warning in
system headers (contrary to my opinion, but I've been in the minority
plenty of times before!) then we should just make that the unconditional
behavior.

(There is, by the way, probably already a workaround: use explicit -I
directives to find these headers as ordinary headers, not as system
headers.  Not to mention fixincludes, which is what we usually use for
OS headers that are unusable with GCC.)

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

|                                             this constant splitting of
| the proverbial baby by creating switches for me to use and switches
| for you to use makes the compiler bigger and the manual fatter without
| much benefit.

At some point, we ought to have a general guidelines about adding
switches to the compiler and better architecture for existing ones.
I guess this is not the time... but when?

| If the consensus turns out to be that we should ignore #warning in

I'm not of the opinion that the compiler should be changed in that
way.

Now that I said that, someone might suspect that as a co-worker I was
irradiated by your opinions; no, mines've formed independently :-)

-- Gaby

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Stan Shebs]

Mark Mitchell wrote:

>
>
> --On Monday, August 12, 2002 06:03:10 PM -0700 Stan Shebs 
> <shebs@apple.com> wrote:
>
>> Geoff Keating wrote:
>>
>>  >Typically a #warning from a system header does indicate an error in
>>  >the use of that header.
>>  >
>> That may be the use that you're familiar with, but that's certainly
>> not required by the specification of the construct.
>
>
> Nothing about the problems you're having are new, as I understand it.
> In other words, nothing about the compiler's behavior changed recently,
> right?

That's right.  I would characterize this as an oversight in the original
definition of #warning.

>
> A little up-front experimentation with #warning/-Werror a while back
> would have saved you (in the collective sense) a lot of grief. :-)

Hindsight is always 20/20, eh?  What I believe happened is that there
are some groups within Apple that use #warning a lot; they may even
have it as part of their coding standard.  I just grepped through
public headers in OS X, and there are several hundred of these; private
headers have even more.  We have other groups that require building
with -Werror before their code can go into the system.  This works
fine until the -Werror folks have to add a feature that involves an
API with the #warnings.

Certainly if there were a god of OS X that could come down and smite
engineers until they agreed on everything, this would not be an issue.
But there is literally no way to get this kind of agreement.  Since
there are no other system vendors using GCC on Apple's scale (Cisco
is probably the closest), it's not surprising that this flaw in
#warning seemed unimportant.

> Even less do I see reasons to add a new switch to change the behavior
> of the compiler.  We simply must stop adding a new switch every time
> the compiler doesn't behave the way we want; this constant splitting of
> the proverbial baby by creating switches for me to use and switches
> for you to use makes the compiler bigger and the manual fatter without
> much benefit.

Benefit to who?  GCC is not a painting to hang on the wall and
admire - it's the system compiler for Apple, and if we can't make it
useful for our users, we'll be laid off and Apple will buy a site
license for CodeWarrior or something.  In fact, one of our selling
points vs CW is that we *can* add switches and be responsive to
users.  FSF GCC doesn't really matter to those users as long as
Apple GCC has the features, but we offer them for FSF GCC in the
belief that if they're useful at Apple, they're quite possibly
useful elsewhere.

In response to your philosophical point, while limiting the
functionality of the compiler saves a little work in the short
term, it's not clever in the long term, because you lose all
your customers.

Stan

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Gabriel Dos Reis]

Stan Shebs <shebs@apple.com> writes:

[...]

| In fact, one of our selling points vs CW is that we *can* add
| switches 

You must have been talking of your own copies of GCC, not FSF
official GCC, since adding a switch to the FSF GCC is not something
that is generally automatic.  A patch do add a switch may even be
rejected... but you already knew that :-)

| FSF GCC doesn't really matter to those users as long as
| Apple GCC has the features,

I agree :-p

-- Gaby

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Stan Shebs]

Gabriel Dos Reis wrote:

>Stan Shebs <shebs@apple.com> writes:
>
>[...]
>
>| In fact, one of our selling points vs CW is that we *can* add
>| switches 
>
>You must have been talking of your own copies of GCC, not FSF
>official GCC, since adding a switch to the FSF GCC is not something
>that is generally automatic.  A patch do add a switch may even be
>rejected... but you already knew that :-)
>
Yeah, FSF GCC is pretty much a nonstarter as Apple's system compiler.
(Apple is not unusual in that respect - few if any system vendors
can use an unmodified FSF GCC.)

Stan

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Mark Mitchell]

> Apple GCC has the features, but we offer them for FSF GCC in the
> belief that if they're useful at Apple, they're quite possibly
> useful elsewhere.

But so far the consensus here seems to be that people don't see this
new switch as useful elsewhere.  So, that's the kind of thing that's
perfect for Apple GCC -- something useful to Apple but not elsewhere.

(If I misread the consensus, I apologize; I may have missed messages
in the thread.)

> In response to your philosophical point, while limiting the
> functionality of the compiler saves a little work in the short
> term, it's not clever in the long term, because you lose all
> your customers.

This is a reduction-to-absurdity argument.

Nobody is suggesting we not add functionality to the compiler; we're
all working on that all the time.  The question is what functionality.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Stan Shebs]

Mark Mitchell wrote:

>> Apple GCC has the features, but we offer them for FSF GCC in the
>> belief that if they're useful at Apple, they're quite possibly
>> useful elsewhere.
>
>
> But so far the consensus here seems to be that people don't see this
> new switch as useful elsewhere.  So, that's the kind of thing that's
> perfect for Apple GCC -- something useful to Apple but not elsewhere.

It seems so.  I wanted to be sure that people understand the
rationale, and not dismiss as "one of those weird Apple things".
Amusingly, one of the other warnings we added turns out to be
identical to the recently-added -Wendif-labels, and I'm glad
not to have to argue about the value of that one!

>> In response to your philosophical point, while limiting the
>> functionality of the compiler saves a little work in the short
>> term, it's not clever in the long term, because you lose all
>> your customers.
>
>
> This is a reduction-to-absurdity argument.
>
> Nobody is suggesting we not add functionality to the compiler; we're
> all working on that all the time.  The question is what functionality.

Well, you did complain about adding switches in general.  I think
it's the wrong thing to complain about, because users generally
consider the wide selection of switchable warnings to be one of
GCC's main strengths.  Have you not ever heard that from users
yourself?

Stan

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Mark Mitchell]

> Well, you did complain about adding switches in general.  I think
> it's the wrong thing to complain about, because users generally
> consider the wide selection of switchable warnings to be one of
> GCC's main strengths.  Have you not ever heard that from users
> yourself?

No; I've heard that they'd really like to be able to control each
warning individually and in particular regions of code the way you
can with most other compilers.  (I produced a patch to do that a
while back, but it never went in.)

But maybe you somehow attract the users who are all happy. :-)

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Mark D. Baushke]

Mark Mitchell <mark@codesourcery.com> writes:
> 
> > Apple GCC has the features, but we offer them for FSF GCC in the
> > belief that if they're useful at Apple, they're quite possibly
> > useful elsewhere.
> 
> But so far the consensus here seems to be that people don't see this
> new switch as useful elsewhere.  So, that's the kind of thing that's
> perfect for Apple GCC -- something useful to Apple but not elsewhere.
>
> (If I misread the consensus, I apologize; I may have missed messages
> in the thread.)

I am not working with Apple stuff, but I would find this patch useful.
 
> Nobody is suggesting we not add functionality to the compiler; we're
> all working on that all the time.  The question is what functionality.

In the general case, I would like to see the interactions of warnings
and errors revisited. One master switch (-Werror) to rule that all
warnings should be treated as errors just does not work as more and more
warnings are added to the system.

	-- Mark

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Mark Mitchell]

> In the general case, I would like to see the interactions of warnings
> and errors revisited. One master switch (-Werror) to rule that all
> warnings should be treated as errors just does not work as more and more
> warnings are added to the system.

I agree.  In fact, I submitted a patch to do what you say some years
back.  With a few more tweaks, I planned to allow you to selectively
turn certain warnings into errors, either from the command-line or
from certain portions of code.

I still think that something like that patch would be a good idea.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Mark D. Baushke]

Mark Mitchell <mark@codesourcery.com> writes:
> 
> > In the general case, I would like to see the interactions of warnings
> > and errors revisited. One master switch (-Werror) to rule that all
> > warnings should be treated as errors just does not work as more and more
> > warnings are added to the system.
> 
> I agree.  In fact, I submitted a patch to do what you say some years
> back.  With a few more tweaks, I planned to allow you to selectively
> turn certain warnings into errors, either from the command-line or
> from certain portions of code.
> 
> I still think that something like that patch would be a good idea.

Yes! That would be a wonderful addition to gcc.

	-- Mark

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Geoff Keating]

> Date: Tue, 13 Aug 2002 11:31:12 -0700
> From: Stan Shebs <shebs@apple.com>

> Hindsight is always 20/20, eh?  What I believe happened is that there
> are some groups within Apple that use #warning a lot; they may even
> have it as part of their coding standard.  I just grepped through
> public headers in OS X, and there are several hundred of these; private
> headers have even more.  We have other groups that require building
> with -Werror before their code can go into the system.  This works
> fine until the -Werror folks have to add a feature that involves an
> API with the #warnings.
> 
> Certainly if there were a god of OS X that could come down and smite
> engineers until they agreed on everything, this would not be an issue.
> But there is literally no way to get this kind of agreement.  Since
> there are no other system vendors using GCC on Apple's scale (Cisco
> is probably the closest), it's not surprising that this flaw in
> #warning seemed unimportant.

Cisco does have similar problems.  They don't, however, use -Werror;
they use grep (or actually something more complicated, I think) on the
compiler's output, which is another possible solution to your problem.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Daniel Egger]

Am Die, 2002-08-13 um 23.47 schrieb Geoff Keating:

> Cisco does have similar problems.  They don't, however, use -Werror;
> they use grep (or actually something more complicated, I think) on the
> compiler's output, which is another possible solution to your problem.

colorgcc? Maybe the Apple people should try it on a framebuffer with a
23" flatscreen. :) That's hell of an impressive development tool if the
framebuffer wasn't so slow.... :/
 
-- 
Servus,
       Daniel

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Zack Weinberg]

On Tue, Aug 13, 2002 at 09:19:29AM -0700, Mark Mitchell wrote:
> If the consensus turns out to be that we should ignore #warning in
> system headers (contrary to my opinion, but I've been in the minority
> plenty of times before!) then we should just make that the unconditional
> behavior.
> 
> (There is, by the way, probably already a workaround: use explicit -I
> directives to find these headers as ordinary headers, not as system
> headers.  Not to mention fixincludes, which is what we usually use for
> OS headers that are unusable with GCC.)

Not to rain on your parade, but we just checked in a patch that makes
your suggested workaround not work anymore (the this-time-for-sure fix
for those annoying 'changing search order' warnings).

While in general I agree with you that we have too many options, I
think that additional warning-control options are not nearly as
problematic as others, since they are usually simple to implement,
easy to document, have narrowly defined semantics, and do not affect
code generation at all (modulo bugs).  As long as we don't have a
general mechanism for disabling individual warnings, I'm inclined to
accede to requests for more finegrained -W options.

zw

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Hans-Peter Nilsson]

On Mon, 26 Aug 2002, Zack Weinberg wrote (to Mark Mitchell):
> On Tue, Aug 13, 2002 at 09:19:29AM -0700, Mark Mitchell wrote:

> While in general I agree with you that we have too many options, I
> think that additional warning-control options are not nearly as
> problematic as others, since they are usually simple to implement,
> easy to document, have narrowly defined semantics, and do not affect
> code generation at all (modulo bugs).  As long as we don't have a
> general mechanism for disabling individual warnings, I'm inclined to
> accede to requests for more finegrained -W options.

I read that as "let's accept the -Wno-warning-directives patch"
:-) and FWIW I agree to that, given your rationale.

brgds, H-P

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Mark D. Baushke]

Geoff Keating <geoffk@geoffk.org> writes:
> 
> Devang Patel <dpatel@apple.com> writes:
> 
> Typically a #warning from a system header does indicate an error in
> the use of that header.

No, a #warning from a system header indicates a warning. A #error
indicates an error.

On my FreeBSD desktop system at work I see warnings like this:

    #warning "this file includes <malloc.h> which is deprecated, use <stdlib.h> instead"

    #warning "this file includes <struct.h> which is deprecated, use <stddef.h> instead"

    #warning "this file includes <values.h> which is obsoleted, use <limits.h> or <float.h> instead"

    #warning "The information in this file should be obtained from <dirent.h>"
    #warning "and is provided solely (and temporarily) for backward compatibility."

Just because the application writer wants to find stop 'real' warnings
specificied on the command line via -W<flagname> switches as errors,
does NOT mean that the #warning provided in a system header file should
be treated as an error without some way to turn it off.

> I proposed more general solution to this sort of problem in
> <http://gcc.gnu.org/ml/gcc/2000-06/msg00639.html>.  An extension to
> this would allow the user to say "if any warning comes from this file,
> it's an error", something like

Hmmm... I have not been overly fond of #pragma directives in the past,
but I would like to see some way to modify how the warnings being
treated as errors mapping is being made. I do not know if this proposal
is the most general as it does require modifying sources which is not
always possible in some environments.

> #pragma gcc warn_error file __FILE__
> 
> That way, the programmer could indicate that particular files, which
> she controls, ought to be warning-free, and let the rest of the world
> go its own way.
> 
> (The programmer can then put the #pragma in header files, which
> catches the common case where the headers generate no warnings when
> the programmer uses them but do when other people use them.)
> 
> -- 
> - Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>
> 

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Devang Patel]

On Tuesday, August 13, 2002, at 10:09  AM, Mark D. Baushke wrote:

> Geoff Keating <geoffk@geoffk.org> writes:
>>
>> Typically a #warning from a system header does indicate an error in
>> the use of that header.
>
> No, a #warning from a system header indicates a warning. A #error
> indicates an error.
>
> On my FreeBSD desktop system at work I see warnings like this:
>
>     #warning "this file includes <malloc.h> which is deprecated, use 
> <stdlib.h> instead"
>
>     #warning "this file includes <struct.h> which is deprecated, use 
> <stddef.h> instead"
>
>     #warning "this file includes <values.h> which is obsoleted, use 
> <limits.h> or <float.h> instead"
>
>     #warning "The information in this file should be obtained from 
> <dirent.h>"
>     #warning "and is provided solely (and temporarily) for backward 
> compatibility."
>
> Just because the application writer wants to find stop 'real' warnings
> specificied on the command line via -W<flagname> switches as errors,
> does NOT mean that the #warning provided in a system header file should
> be treated as an error without some way to turn it off.

I agree.

>> I proposed more general solution to this sort of problem in
>> <http://gcc.gnu.org/ml/gcc/2000-06/msg00639.html>.  An extension to
>> this would allow the user to say "if any warning comes from this file,
>> it's an error", something like
>
> Hmmm... I have not been overly fond of #pragma directives in the past,
> but I would like to see some way to modify how the warnings being
> treated as errors mapping is being made. I do not know if this proposal
> is the most general as it does require modifying sources which is not
> always possible in some environments.

I agree on this one also.

-Devang

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Gabriel Dos Reis]

"Mark D. Baushke" <mdb@gnu.org> writes:

| Geoff Keating <geoffk@geoffk.org> writes:
| > 
| > Devang Patel <dpatel@apple.com> writes:
| > 
| > Typically a #warning from a system header does indicate an error in
| > the use of that header.
| 
| No, a #warning from a system header indicates a warning. A #error
| indicates an error.
| 
| On my FreeBSD desktop system at work I see warnings like this:
| 
|     #warning "this file includes <malloc.h> which is deprecated, use <stdlib.h> instead"

For V3, people are advised  to use -Wno-deprecated to silence similar things.

-- Gaby

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Richard Henderson]

On Mon, Aug 12, 2002 at 05:00:05PM -0700, Devang Patel wrote:
> >If the argument is that this warning comes from third-party header
> >files, the counter-argument is that the third party probably put
> >it in there for a reason, and that if you ignore the warning you
> >may well not understand the input constraints of the package.
> >
> 
> What if it is coming from system headers ?

That still fits the description of third party from my point
of view: not the compiler and not the programmer.


r~

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Devang Patel]

On Monday, August 12, 2002, at 06:25  PM, Richard Henderson wrote:

> On Mon, Aug 12, 2002 at 05:00:05PM -0700, Devang Patel wrote:
>>> If the argument is that this warning comes from third-party header
>>> files, the counter-argument is that the third party probably put
>>> it in there for a reason, and that if you ignore the warning you
>>> may well not understand the input constraints of the package.
>>>
>>
>> What if it is coming from system headers ?
>
> That still fits the description of third party from my point
> of view: not the compiler and not the programmer.

It is different from third-party header. You may have freedom to use
particular version of third-party component but not system headers.

In Software release cycle, there are times when you're not allowed to
touch your source for a given release. They are frozen at a time.
Now imagine Mr. X

- Mr X is a software developer and develops software Z.
- Z is part of one particular OS released
   targeted for particular date.
- Z is frozen as of today for OS release and it uses math library.
- Some other component in OS needs higher precision math and it is an
   important component so system gets new math library.
- Math library provider puts a #warning message about new functions.
- Z uses -Werror and now it does not build.

   You may argue that X needs to fix Z to use new APIs, but in real life
   if there are 1000 such projects and fixing and testing each of them
   may take couple of months to stabilize everything.

my thoughts,
-Devang

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Daniel Jacobowitz]

On Mon, Aug 12, 2002 at 06:59:28PM -0700, Devang Patel wrote:
> 
> On Monday, August 12, 2002, at 06:25  PM, Richard Henderson wrote:
> 
> >On Mon, Aug 12, 2002 at 05:00:05PM -0700, Devang Patel wrote:
> >>>If the argument is that this warning comes from third-party header
> >>>files, the counter-argument is that the third party probably put
> >>>it in there for a reason, and that if you ignore the warning you
> >>>may well not understand the input constraints of the package.
> >>>
> >>
> >>What if it is coming from system headers ?
> >
> >That still fits the description of third party from my point
> >of view: not the compiler and not the programmer.
> 
> It is different from third-party header. You may have freedom to use
> particular version of third-party component but not system headers.
> 
> In Software release cycle, there are times when you're not allowed to
> touch your source for a given release. They are frozen at a time.
> Now imagine Mr. X
> 
> - Mr X is a software developer and develops software Z.
> - Z is part of one particular OS released
>   targeted for particular date.
> - Z is frozen as of today for OS release and it uses math library.
> - Some other component in OS needs higher precision math and it is an
>   important component so system gets new math library.
> - Math library provider puts a #warning message about new functions.
> - Z uses -Werror and now it does not build.
> 
>   You may argue that X needs to fix Z to use new APIs, but in real life
>   if there are 1000 such projects and fixing and testing each of them
>   may take couple of months to stabilize everything.

That's not a valid reason, in my opinion.  The new math library should
have #warning only off on a dev branch somewhere if it's sneaking in at
a time when components can not be upgraded to match!  That's release
management; you don't deprecate interfaces at the last minute.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Devang Patel]

On Monday, August 12, 2002, at 07:06  PM, Daniel Jacobowitz wrote:

> On Mon, Aug 12, 2002 at 06:59:28PM -0700, Devang Patel wrote:
>>
>> On Monday, August 12, 2002, at 06:25  PM, Richard Henderson wrote:
>>
>>> On Mon, Aug 12, 2002 at 05:00:05PM -0700, Devang Patel wrote:
>>>>> If the argument is that this warning comes from third-party header
>>>>> files, the counter-argument is that the third party probably put
>>>>> it in there for a reason, and that if you ignore the warning you
>>>>> may well not understand the input constraints of the package.
>>>>>
>>>>
>>>> What if it is coming from system headers ?
>>>
>>> That still fits the description of third party from my point
>>> of view: not the compiler and not the programmer.
>>
>> It is different from third-party header. You may have freedom to use
>> particular version of third-party component but not system headers.
>>
>> In Software release cycle, there are times when you're not allowed to
>> touch your source for a given release. They are frozen at a time.
>> Now imagine Mr. X
>>
>> - Mr X is a software developer and develops software Z.
>> - Z is part of one particular OS released
>>   targeted for particular date.
>> - Z is frozen as of today for OS release and it uses math library.
>> - Some other component in OS needs higher precision math and it is an
>>   important component so system gets new math library.
>> - Math library provider puts a #warning message about new functions.
>> - Z uses -Werror and now it does not build.
>>
>>   You may argue that X needs to fix Z to use new APIs, but in real 
>> life
>>   if there are 1000 such projects and fixing and testing each of them
>>   may take couple of months to stabilize everything.
>
> That's not a valid reason, in my opinion.  The new math library should
> have #warning only off on a dev branch somewhere if it's sneaking in at
> a time when components can not be upgraded to match!

It is sneaking in at a time when some component can be upgraded but not
all. Think if, Mr. X is an external developer. At last
minute OS release management may not want to wait for another drop of Z
from external sources but still wants to upgrade math lib. for other
components. And release manager can't release OS without Z.

> That's release
> management; you don't deprecate interfaces at the last minute.

When different component work on different time line, it is not easy to
synchronize and decide what is the 'last minute' for all project.

-Devang

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Mark Mitchell]

--On Monday, August 12, 2002 04:42:55 PM -0700 Richard Henderson 
<rth@redhat.com> wrote:

> On Mon, Aug 12, 2002 at 04:08:57PM -0700, Devang Patel wrote:
>> It was a long thread. But just like we have an option to disable
>> warnings from system header, somebody may need an options to
>> disable #warning messages.
>
> I'm not particularly friendly to this option.
>
> Warnings from the compiler are something over which you have less
> control, whereas you have complete control over warning directives.

Me neither.  I've nothing new to add; just chiming in to agree with
Richard.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Neil Booth]

Richard Henderson wrote:-

> If the argument is that this warning comes from third-party header
> files, the counter-argument is that the third party probably put
> it in there for a reason, and that if you ignore the warning you
> may well not understand the input constraints of the package.

Indeed - we had a PR where someone complained that #warnings were
switched off in system headers, so we changed it so #warning is
an exception to the "no warnings in system headers" rule.

Neil.

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Stan Shebs]

Neil Booth wrote:

>Devang Patel wrote:-
>
>Here is the patch.
>OK to commit  ?
>
>
>Could you remind me of the rationale for this switch again?
>
This is what I've seen - evil library developers putting #warning into
headers, vs user code compiling with -Werror.  Sure, it was handy to
see the #warning the first time, but it's unreasonable to expect everyone
to stop using -Werror until all the #warnings are removed.

Stan

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Richard Henderson]

On Mon, Aug 12, 2002 at 04:41:10PM -0700, Stan Shebs wrote:
> Sure, it was handy to see the #warning the first time, but it's
> unreasonable to expect everyone to stop using -Werror until all
> the #warnings are removed.

Why?  That's what -Werror is *for* -- to prevent you 
from ignoring warnings.  If that's not what you want,
don't use it.


r~

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Stan Shebs]

Richard Henderson wrote:

>On Mon, Aug 12, 2002 at 04:41:10PM -0700, Stan Shebs wrote:
>
>>Sure, it was handy to see the #warning the first time, but it's
>>unreasonable to expect everyone to stop using -Werror until all
>>the #warnings are removed.
>>
>
>Why?  That's what -Werror is *for* -- to prevent you 
>from ignoring warnings.  If that's not what you want,
>don't use it.
>
That's why I said "handy to see the first time".  If you have a project
carefully set up so that -Werror works, and you depend on it to catch
coding errors in your code, you're screwed if an evil header developer
adds something like

    #warning "Revisit this typedef after Jaguar ships."

I suspect it doesn't seem very important because #warning is not often
used, and so few people have bumped into the conundrum of needing to
ignore warnings issued from places that they already know they don't
care about.  Some groups within Apple use this a lot - it's there, so
why not? - and without the ability to suppress #warning, other groups
using -Werror are stuck with losing their ability to detect mistakes
in their own code.  (Note that the headers in question may not fit the
definition of "system headers".)

Stan

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Richard Henderson]

On Mon, Aug 12, 2002 at 05:31:56PM -0700, Stan Shebs wrote:
> ... you're screwed if an evil header developer adds something like
> 
>    #warning "Revisit this typedef after Jaguar ships."

Well, yes, you are screwed.  I can't help it if some of
your developers are idiots.  All I can suggest is that
you teach them to do otherwise.  And then edit your local
copy of the header to delete the warning.

It's similar to the problem of glibc using gcc extensions
without __extension__, which generates -pedantic warnings.
(Except that Uli fixes these when found.  ;-)


r~

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Devang Patel]

On Monday, August 12, 2002, at 06:35  PM, Richard Henderson wrote:

> On Mon, Aug 12, 2002 at 05:31:56PM -0700, Stan Shebs wrote:
>> ... you're screwed if an evil header developer adds something like
>>
>>    #warning "Revisit this typedef after Jaguar ships."
>
> Well, yes, you are screwed.  I can't help it if some of
> your developers are idiots.  All I can suggest is that
> you teach them to do otherwise.  And then edit your local
> copy of the header to delete the warning.
>
> It's similar to the problem of glibc using gcc extensions
> without __extension__, which generates -pedantic warnings.
> (Except that Uli fixes these when found.  ;-)
>

In that case, is it appropriate to argue that gcc does
not need "-Wno-system-headers" flag ?

-Devang

In theory, there is no difference between theory and practice,
but in practice, there is.  -Unknown

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Stan Shebs]

Richard Henderson wrote:

>On Mon, Aug 12, 2002 at 05:31:56PM -0700, Stan Shebs wrote:
>
>>... you're screwed if an evil header developer adds something like
>>
>>   #warning "Revisit this typedef after Jaguar ships."
>>
>
>Well, yes, you are screwed.  I can't help it if some of
>your developers are idiots.
>
Yeah, GCC could be a lot simpler all around if we only let smart
people use it.

Stan

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Mark D. Baushke]

Richard Henderson <rth@redhat.com>
> 
> On Mon, Aug 12, 2002 at 04:41:10PM -0700, Stan Shebs wrote:
> > Sure, it was handy to see the #warning the first time, but it's
> > unreasonable to expect everyone to stop using -Werror until all
> > the #warnings are removed.
> 
> Why?  That's what -Werror is *for* -- to prevent you 
> from ignoring warnings.  If that's not what you want,
> don't use it.

And if you WANT to catch the -Wuninitialized warnings with an error, but
you do NOT want to be stopped by the idiot /usr/include/foo.h that puts
a #warning into their .h file for no good reason?

The -Werror hammer is often too coarse grained with all of the possible
warnings that can be generated during a build. Until and unless we can
more selectively turn off 'warnings' the -Werror switch will continue to
be a pain to use.

	-- Mark

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Geoff Keating]

"Mark D. Baushke" <mdb@gnu.org> writes:

> Richard Henderson <rth@redhat.com>
> > 
> > On Mon, Aug 12, 2002 at 04:41:10PM -0700, Stan Shebs wrote:
> > > Sure, it was handy to see the #warning the first time, but it's
> > > unreasonable to expect everyone to stop using -Werror until all
> > > the #warnings are removed.
> > 
> > Why?  That's what -Werror is *for* -- to prevent you 
> > from ignoring warnings.  If that's not what you want,
> > don't use it.
> 
> And if you WANT to catch the -Wuninitialized warnings with an error, but
> you do NOT want to be stopped by the idiot /usr/include/foo.h that puts
> a #warning into their .h file for no good reason?

The solution we usually recommend for this is to use sed or grep on
the compiler's output.  Various solutions have been proposed to
integrate that functionality into the compiler, but no-one has yet
wanted it badly enough to implement any of them.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>

Re: PATCH: Wno-warning-directives [WasRe: cpplib: Start moving ...]

[Neil Booth]

Stan Shebs wrote:-

> This is what I've seen - evil library developers putting #warning into
> headers, vs user code compiling with -Werror.  Sure, it was handy to
> see the #warning the first time, but it's unreasonable to expect everyone
> to stop using -Werror until all the #warnings are removed.

Hmm.  Maybe time for #note or #notice?

Neil.

Re: cpplib: Start moving switch handling to front ends

[Nathan Sidwell]

Devang Patel wrote:

> Personally I do not have hard opinion about this, but I have not seen
> any guide-lines about use of special chars like '#' in warning names.
> 
> If everybody thinks, it is not OK then I will change it to
> -Wno-pound-warnings.
'scuse me, but over here pound is not the name of the #
char, 'cos that is a much better name for another character
which may or may not be rendered correctly as '£'
I know gcc is written in US english, but let's try not to
be confusing!

From the jargon file:
	The pronunciation of # as `pound' is common in the U.S. but a
	bad idea; Commonwealth Hackish has its own, rather more apposite
	use of `pound sign' (confusingly, on British keyboards the pound
	graphic happens to replace #; thus Britishers sometimes call #
	on a U.S.-ASCII keyboard `pound', compounding the American error).
	The U.S. usage derives from an old-fashioned commercial practice
	of using a # suffix to tag pound weights on bills of lading. The
	character is usually pronounced `hash' outside the U.S. There
	are more culture wars over the correct pronunciation of this
	character than any other, which has led to the ha ha only serious
	suggestion that it be pronounced `shibboleth' (see Judges 12:6 in
	an Old Testament or Tanakh). 

nathan

-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org