headers
Stepan Kasal | 4 Jan 2006 16:12
Picon

Re: Happy new year and new bug found in m4.

Hello,

On Mon, Jan 02, 2006 at 11:50:39AM +0100, aikido87 wrote:
> First of all, thanks for all your work, good people at gnu project.
> Second, Happy New Year, also for your families. 

you are welcome, and happy new year to you, too.

> ifelse (include (file.txt), undivert (file.txt), ...

Indeed, the second parameter is empty, and this is the documented
behaviour.  Unlike `include', `undivert' doesn't _expand_ to the contents
of the file.  Instead, it puts the contents of the file to the output
stream and expands to nothing.

Have a blessed year,
	Stepan Kasal

_______________________________________________
bug-gnu-utils <at> gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnu-utils
Permalink | Reply | 0 comments |
headers
Ilya N. Golubev | 10 Jan 2006 21:21
Picon

push_string_init calling check

CVS branch: branch-1_4

<recursive push_string with non-gnu cc> posted on Thu, 10 Nov 2005
18:08:17 +0300 (<027a4373626100-gin <at> mo.msk.ru>) describes an internal
error that occurs in certain build configurations unconditionally once
certain line of C code is executed, one with `push_string_init ()'
passed to macro.  Batch oriented tests done by `make check' should
readily detect that, but they do not, all of them are passed.  `gcov'
shows that, when m4 built with gcc, that line is never executed by
tests either.  Fixing that as follows.  (Certainly test file name is
unimportant and may be easily changed as long as it matches
`*[0-9][0-9].*'.)

	* checks/58.changequote: New, to detect internal error fixed in
	2005-12-04 change.

--- /dev/null	1970-01-01 03:00:00.000000000 +0300
+++ checks/58.changequote	2006-01-02 01:26:34.340687712 +0300
 <at>  <at>  -0,0 +1,4  <at>  <at> 
+changequote(----,+)
+dnl  <at> result{}
+----+---
+dnl  <at> result{}---
Permalink | Reply | 3 comments |
headers
Mohamed KAABI | 16 Jan 2006 21:30

M4 1.4 versus m4 1.4.4

Hello all,

I'm installing the autoconf tool on HP machine.
Since this tool needs m4 I installed it.

The command "m4 --version" gives the result below

GNU M4 1.4.4
Written by Rene' Seindal.

But configuring autoconf results on the following error:

checking whether m4 supports frozen files... no
configure: error: GNU M4 1.4 is required

Would you have any comment to help me resolve this problem.

Thanks and regards,
Mohamed KAABI.
Permalink | Reply | 1 comment |
headers
Stepan Kasal | 17 Jan 2006 10:59
Picon

Re: M4 1.4 versus m4 1.4.4

Hello,

On Mon, Jan 16, 2006 at 09:30:43PM +0100, Mohamed KAABI wrote:
> GNU M4 1.4.4
[...] 
> checking whether m4 supports frozen files... no
> configure: error: GNU M4 1.4 is required

this check is done by the following code:

  case `$M4 --help < /dev/null 2>&1` in
    *reload-state*) ac_cv_prog_gnu_m4=yes ;;
  esac

How it comes that it doesn't pass?  What is the value of M4 at that
point?

I'm afraid that only you are in the position to find the reason.

> Would you have any comment to help me resolve this problem.

Hpe this helps you,
	Stepan Kasal
Permalink | Reply | 0 comments |
headers
john | 19 Jan 2006 03:37

dangling pointer bug and proposed patch

Hello,

There is a dangling pointer bug in GNU m4, exposed by this example:

$ m4 -dqeat
define(`f',`one')f(undefine(`f')`two')
m4trace: -1- define(`f', `one')
m4trace: -2- undefine(`f')
m4trace: -1- øò·øò·(`two') -> `øò·øò·H'
øò·øò·H

The problem is that undefining a macro while it is in the "collect
arguments" phase leaves a dangling symbol pointer on the stack.  Bug
aside, the GNU m4 info file doesn't seem to specify what *should*
happen in this situation.  I propose that when a macro whose arguments
have just been expanded discovers that its pre-argument-expansion
definition has been deleted, it should use the "current" definition
(i.e. the same definition a new invocation of the macro would use).
If no current definition exists, the macro should use the expansion
$0($ <at> ), which treats the macro as effectively undefined, except that
leading whitespace is stripped from the arguments.

I've written up the gory details (mostly to help me make sure I
understand them), including justification of the proposed behaviour,
in the attached PDF.

A patch for the proposed fix against m4-1.4.4 is also attached.
(The branch name m4-1.4.4.1 is just for my own convenience.)

Regards,
(Continue reading)

Permalink | Reply | 11 comments |
headers
Eric Blake | 19 Jan 2006 14:18
Gravatar

Re: dangling pointer bug and proposed patch


[moving discussion to m4-patches]

According to john on 1/18/2006 7:37 PM:
> Hello,
> 
> There is a dangling pointer bug in GNU m4, exposed by this example:
> 
> $ m4 -dqeat
> define(`f',`one')f(undefine(`f')`two')
> m4trace: -1- define(`f', `one')
> m4trace: -2- undefine(`f')
> m4trace: -1- øò·øò·(`two') -> `øò·øò·H'
> øò·øò·H

Thanks for catching that, and a great analysis of the issue!

Also, could you check if the bug is still present on CVS head?

> 
> A patch for the proposed fix against m4-1.4.4 is also attached.
> (The branch name m4-1.4.4.1 is just for my own convenience.)

Unfortunately, the patch is too big to be considered trivial; are you
willing to assign copyright to the FSF?  This is a legal necessity before
your patch can be applied.

--
Life is short - so eat dessert first!
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stepan Kasal | 20 Jan 2006 12:39
Picon

Bug report address in branch 1.4

Hello,
  I noticed that m4.texinfo in the 1.4 branch still contains:

send e-mail to (Internet) bug-gnu-utils <at>  <at> prep.ai.mit.edu or
(UUCP) mit-eddie!prep.ai.mit.edu!bug-gnu-utils.

Could you please replace it with the new mail address, in case
1.4.5 is ever released?

Have a nice day,
	Stepan Kasal
Permalink | Reply | 2 comments |
headers
Eric Blake | 25 Jan 2006 15:00
Gravatar

Re: HEAD: cygwin make test report - 9 tests failed


Hi Gary,

According to Gary V. Vaughan on 9/11/2005 4:12 PM:
> 
> Incidentally, do you have paperwork on file with the FSF?  I'd be happy
> to give you an m4 commit bit to iron out any wrinkles if that will be of
> any use to you?

My FSF copyright papers were finally put on file on Jan 18.  Maybe it's
time I take you up on your offer for commit privileges, so I can help with
some of the backlog of trivial patches that have been collecting on this
list.  This would include helping me set up an account on the GNU
machines, so that I can help track copyright assignments.

> 
> Cheers,
> 	Gary.

--
Life is short - so eat dessert first!

Eric Blake             ebb9 <at> byu.net
Permalink | Reply | 0 comments |

Gmane