headers
Translation Project Robot | 5 Feb 2008 15:17

New Chinese (simplified) PO file for 'm4' (version 1.4o)

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'm4' has been submitted
by the Chinese (simplified) team of translators.  The file is available at:

    http://translationproject.org/latest/m4/zh_CN.po

(We can arrange things so that in the future such files are automatically
e-mailed to you when they arrive.  Ask at the address below if you want this.)

All other PO files for your package are available in:

    http://translationproject.org/latest/m4/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

    http://translationproject.org/domain/m4.html

If any question arises, please contact the translation coordinator.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ralf Wildenhues | 13 Feb 2008 23:36
Picon
Picon

generating testsuite in bootstrap?

Hello,

is it worthwhile to generate m4/tests/testsuite from within bootstrap,
so that then,
  ./configure && make all install

does not need the autotools?

Cheers,
Ralf
Permalink | Reply | 1 comment |
headers
Eric Blake | 14 Feb 2008 02:00
Gravatar

Re: generating testsuite in bootstrap?


According to Ralf Wildenhues on 2/13/2008 3:36 PM:
| Hello,
|
| is it worthwhile to generate m4/tests/testsuite from within bootstrap,
| so that then,
|   ./configure && make all install
|
| does not need the autotools?

Sounds like a good argument to me - allowing you to run bootstrap on a git
checkout on a full-fledged machine, then copy the directory structure over
to a punier machine to see how things fare.  However, looking at history:

http://git.sv.gnu.org/gitweb/?p=m4.git;a=commitdiff;h=be70d90

there was a point in time where half of the testsuite was generated at
bootstrap (but not the part that required autom4te).  So this would be a
change in the opposite direction.  I'm also worried about timestamps; one
of the tests makes sure __m4_version__ outputs the same thing as what
configure.ac uses, and I still haven't gotten git-version-gen working
nicely with m4.  I'll play with the idea some, but it's too early to tell
whether I'll commit a patch along these lines.  Fortunately, 'make dist'
makes sure the testsuite is up-to-date, so a snapshot tarball does not
need autotools to be tested.

--
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9 <at> byu.net
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ralf Wildenhues | 20 Feb 2008 22:01
Picon
Picon

distcheck fails test 056

Hi Eric,

I'm seeing a test failure of test 056 on branch-1_4 with
--enable-changeword; valgrind warns with or without the switch though:

Checking ../../checks/056.indir
 <at>  ../doc/m4.texinfo:2440: Origin of test
../../checks/056.indir: stderr mismatch
--- m4-tmp.19265/m4-xerr        2008-02-18 10:53:40.000000000 +0100
+++ m4-tmp.19265/m4-err 2008-02-18 10:53:40.000000000 +0100
 <at>  <at>  -1 +1  <at>  <at> 
-m4:stdin:3: Warning: %%\:\\\nodd: extra arguments ignored: 1 > 0
+m4:stdin:3: Warning: %%\:\\\nodd\337\252\252*: extra arguments ignored: 1 > 0

==8387== Conditional jump or move depends on uninitialised value(s)
==8387==    at 0x41F811: quotearg_buffer_restyled (quotearg.c:296)
==8387==    by 0x41FD0F: quotearg_n_options (quotearg.c:723)
==8387==    by 0x41FDF6: quotearg_n (quotearg.c:743)
==8387==    by 0x41FE3C: quotearg (quotearg.c:755)
==8387==    by 0x4027CF: m4_verror_at_line (m4.c:121)
==8387==    by 0x402C83: m4_warn (m4.c:189)
==8387==    by 0x4040F2: bad_argc (builtin.c:509)
==8387==    by 0x405B59: m4_divnum (builtin.c:1234)
==8387==    by 0x4122B3: call_macro (macro.c:575)
==8387==    by 0x4050B4: m4_indir (builtin.c:954)
==8387==    by 0x4122B3: call_macro (macro.c:575)
==8387==    by 0x412D65: expand_macro (macro.c:676)

Cheers,
Ralf
(Continue reading)

Permalink | Reply | 2 comments |
headers
anonymous | 20 Feb 2008 22:59
Picon

[sr #106268] Please implement -M option for M4!


URL:
  <http://savannah.gnu.org/support/?106268>

                 Summary: Please implement -M option for M4!
                 Project: GNU M4
            Submitted by: None
            Submitted on: Wednesday 02/20/2008 at 21:59 UTC
                Category: None
                Priority: 5 - Normal
                Severity: 1 - Wish
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: David <at> Warme.net
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: None

    _______________________________________________________

Details:

It would be very nice if GNU M4 supported the -M flag
(and perhaps -MM) like GCC (which has had it for ages).

Over the years I have had several encounters with
Richard M. Stallman of the following form:

DMW: Adding a %include directive to bison would be a nice
(Continue reading)

Permalink | Reply | 501 comments |
headers
Eric Blake | 21 Feb 2008 01:08
Gravatar

Re: distcheck fails test 056

> Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> writes:

Hi Ralf, and thanks for spotting this (the bug is highly dependent on what is 
already on the heap, but I haven't been able to get valgrind to run on cygwin).

> ==8387== Conditional jump or move depends on uninitialised value(s)
> ==8387==    at 0x41F811: quotearg_buffer_restyled (quotearg.c:296)
> ==8387==    by 0x41FD0F: quotearg_n_options (quotearg.c:723)
> ==8387==    by 0x41FDF6: quotearg_n (quotearg.c:743)
> ==8387==    by 0x41FE3C: quotearg (quotearg.c:755)
> ==8387==    by 0x4027CF: m4_verror_at_line (m4.c:121)

Sure enough, I forgot to terminate the array.  Not a problem on the argv_ref 
branch (but only because I switched to length-based processing instead of NUL-
termination-based).  Committing this to branch and head.

From: Eric Blake <ebb9 <at> byu.net>
Date: Wed, 20 Feb 2008 17:02:06 -0700
Subject: [PATCH] Fix out-of-bounds read for sanitized macro names, from 2008-02-
06.

* src/m4.c (m4_verror_at_line): Properly terminate the string.
Reported by Ralf Wildenhues.

Signed-off-by: Eric Blake <ebb9 <at> byu.net>
---
 ChangeLog |    6 ++++++
 src/m4.c  |    1 +
 2 files changed, 7 insertions(+), 0 deletions(-)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Blake | 21 Feb 2008 03:07
Picon

[sr #106268] Please implement -M option for M4!


Update of sr #106268 (project m4):

                  Status:                    None => Confirmed              

    _______________________________________________________

Follow-up Comment #1:

Hmm.  git head already provides -M to mean --module-directory, which has
nothing to do with dependency tracking, so we would have to use a different
letter (or if Gary's idea of simplifying modules pans out, free it up for a
better use).  However, the idea of dependency tracking is reasonable, and in
fact is already in the TODO from several years ago:

  + Make m4 show include dependencies like gcc so Makefile targets are
    updated when their (included) input files are updated (Erick B).

All we need is a volunteer with enough time and desire to implement it.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?106268>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/
(Continue reading)

Permalink | Reply | 501 comments |
headers
anonymous | 21 Feb 2008 18:34
Picon

[sr #106268] Please implement -M option for M4!


Follow-up Comment #2, sr #106268 (project m4):

Thanks Eric,

I specified -M more for the ability to refer directly
to GCC's interface definition than anything else.  Call
it --supercalifragilisticexpialidocious if you must...

The best news for me to take away from this is that
the M4 developers consider this to be A Good Thing (tm),
and would be willing to include it in a future release
if we were to implement it.

I will check with my supervisor to see whether or not
such a "volunteer" exists within our organization...

David Warme

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/support/?106268>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/
Permalink | Reply | 0 comments |

Gmane