Re: `#error' vs string literal

[Ralf Wildenhues]

Ping.  It'd be nice to know if this has a chance of being acceptable,
or if I should just drop it.

Cheers,
Ralf

* Ralf Wildenhues wrote on Fri, Mar 17, 2006 at 05:50:37AM CET:
>       * 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
> 
>