headers
Paul Eggert | 19 Feb 2004 05:56

Re: RCS and m4 ported to nsr-tandem-nsk

> From: "Bates, Tom" <tom.bates <at> hp.com>
> Date: Tue, 17 Feb 2004 10:10:15 -0600

> +#ifdef __TANDEM
> +#include <floss.h>
> +#endif

Thanks, but this is the first I've ever heard of __TANDEM or
<floss.h>.  Why is it needed here?  Where is this stuff documented?
I'd like to understand because I'd rather fix the underyling problem
with 'configure' magic; that way, we wouldn't need to modify the
C-language source.

I see you posted a similar fix to bug-m4 <at> gnu.org in
<http://mail.gnu.org/archive/html/bug-m4/2004-01/msg00066.html>
so I'll CC: this message there, too.

To answer your other question in your message to bug-m4: to modify
config.guess and config.sub, please send patches to
<config-patches <at> gnu.org>.  Submit a context diff and a properly
formatted ChangeLog entry.  Thanks.
Permalink | Reply | 0 comments |
headers
Stepan Kasal | 20 Feb 2004 08:12
Picon

Re: macro expansion

Hello,

On Thu, Feb 19, 2004 at 10:23:35AM -0500, Anupama Lath wrote:
> WrIregNops( venMfunc_8, `0x'eval( KLENGTH_9|(72-1), 16 ) )
> 				  ^                                ^
> 
> which do not get evaluated by the GNU m4 1.4 unless the spaces 
> are removed. Looks like this is the syntax imposed by GNU m4.
> Is there any chance of this limitation being changed ?

I would guess that this is a bug in m4 1.4.
It seems to be fixed in the current CVS version.
(You can check it from savannah.gnu.org, if you have automake and
autoconf, and if you can take the risk.)

The only space causing problems is the space _after_ the second
parameter to `eval'.  You can workaround the problem this way:

define(KLENGTH_9, 8 )
define(`orig_eval', defn(`eval'))
define(`eval', `orig_eval($1,orig_eval($2))')
WrIregNops( venMfunc_8, `0x'eval( KLENGTH_9|(72-1), 16 ) )

The code could be simpler, if you use "m4 -P" to process the files:

m4_dnl  use m4 -P
m4_define(KLENGTH_9, 8 )
m4_define(`eval', `m4_eval($1,m4_eval($2))')
WrIregNops( venMfunc_8, `0x'eval( KLENGTH_9|(72-1), 16 ) )
(Continue reading)

Permalink | Reply | 0 comments |
headers
Anupama Lath | 23 Feb 2004 16:33

'eval' macro expansion

I have an expression like this in my input. 
The m4 macroprocessor throws an error if there are spaces before the 
opening/closing parantheses.
eval ( 12| ( 72-1 ) , 16 )
     ^                        ^
Is this a bug in gnu m4 1.4.

Thanks,
Anupama.

******************Legal Disclaimer**************************
"This email may contain confidential and privileged material for the sole use of the intended recipient. 
Any unauthorized review, use or distribution by others is strictly prohibited.  If you have received the
message in error, please advise the sender by reply email help <at> globespanvirata.com, and delete the
message. Thank you."
****************************************************************
Permalink | Reply | 1 comment |
headers
Gary V. Vaughan | 24 Feb 2004 10:03
Picon
Gravatar

Re: 'eval' macro expansion


Anupama Lath wrote:
| I have an expression like this in my input.
| The m4 macroprocessor throws an error if there are spaces before the
| opening/closing parantheses.
| eval ( 12| ( 72-1 ) , 16 )
|      ^                        ^
| Is this a bug in gnu m4 1.4.

~From the manual:

Macro invocation
================

Macro invocations has one of the forms

~     name

which is a macro invocation without any arguments, or

~     name(arg1, arg2, ..., argN)

which is a macro invocation with N arguments.  Macros can have any
number of arguments.  All arguments are strings, but different macros
might interpret the arguments in different ways.

~   The opening parenthesis *must* follow the NAME directly, with no
spaces in between.  If it does not, the macro is called with no
arguments at all.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane