[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: `#error' vs string literal
From: |
Ralf Wildenhues |
Subject: |
Re: `#error' vs string literal |
Date: |
Wed, 5 Apr 2006 18:22:14 +0200 |
User-agent: |
Mutt/1.5.11 |
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
>
>
- Re: `#error' vs string literal,
Ralf Wildenhues <=