Re: `#error' vs string literal

[Ralf Wildenhues]

* Paul Eggert wrote on Tue, Mar 07, 2006 at 06:48:32PM CET:
> 
> The distinction here is that one should probably not rely on #error
> within .m4 tests, since the results of the tests might not be
> reliable.  But within ordinary C code, #error is fine; people with
> losing compilers will simply have to look at the compilers' diagnostic
> output.
> 
> Advice along these lines should be added to the autoconf manual; I'll
> add this to my list of things to do.

Suggested patch below.  I'm not /really/ sure about what I'm writing,
though.

Cheers,
Ralf

        * doc/autoconf.texi (Specific Compiler Characteristics):
        Document `#error' limitations.

Index: doc/autoconf.texi
===================================================================
RCS file: /cvsroot/autoconf/autoconf/doc/autoconf.texi,v
retrieving revision 1.966
diff -u -r1.966 autoconf.texi
--- doc/autoconf.texi   15 Mar 2006 14:02:36 -0000      1.966
+++ doc/autoconf.texi   17 Mar 2006 04:48:50 -0000
@@ -5675,6 +6032,19 @@
 not from the @code{? 1 : -1}, and
 Autoconf works around this problem by casting @code{sizeof (int)} to
 @code{long int} before comparing it.
+
address@hidden @samp{#error}
address@hidden @samp{#error}
+Some preprocessors, such as the one invoked by the @sc{irix} compiler,
+do not fail over @samp{#error} by default.  In most cases it is
+sufficient to provoke a compiler failure rather than a preprocessor
+failure.  It is then safe to replace @samp{#error foo not supported}
+with @samp{"error: foo not supported"} in Autoconf macros to provoke
+such a failure.
+
+On the other hand, the traditional Solaris preprocessor @command{/lib/cpp}
+does not understand @samp{#error} and fails to successfully preprocess it
+even if it is conditionalized away.
 @end table
 
 @node Generic Compiler Characteristics