headers
Eric Blake | 1 May 2007 14:48
Gravatar

Re: Integer wraparound bug with eval on OS X


According to Gary V. Vaughan on 4/30/2007 10:49 AM:
> Hi Eric,
> 
> I think your recent patch to eval has either broken something, or else
> tickled a long standing bug.  Using the latest gnulib and m4 HEAD, test
> 135 is failing.

> eval(-4 >> 65)
> -1
> eval(-4 >> 64)
> -1
> eval(-4 >> 63)
> -1

It looks like the failure is due to undefined C code (shifting by an
amount larger than the width of the type), and that the testsuite is just
tickling a long-standing bug.  branch-1_4 is immune because it
intentionally masks the shift amount to bring it back into width, so I
will have to port some of that code to HEAD.  Thanks for the heads-up on this.

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

Eric Blake             ebb9 <at> byu.net
Permalink | Reply | 2 comments |
headers
MS | 9 May 2007 16:05

M4 buffering problem? 0d0a -> 0d0d0a

Hello,

Versions : 

i tried M4 1.4 and M4 1.4.7 which both shows the problem
M4 1.4.4 do not show the problem, but i cannot see a comment, that something
is fixed in this area

Preprocess a file with the following content
'a' 
and then some 9000 x "0x0d 0x0a" 

Then the output is very similar to the input, except that on all offsets
divisible by 1024 (0x400) the sequence 0d0a changes to
0d0d0a.

Note : 

sourcefile 
offset 1023 : 0D
offset 1024 : 0A
offset 1025 : 0D
....

TargetFile
offset 1023 : 0D
offset 1024 : 0D (!!)
offset 1025 : 0A

When the first 'a' is replaced by, nothing or by 'aa' then the problem does
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eric Blake | 11 May 2007 02:08
Gravatar

Re: M4 buffering problem? 0d0a -> 0d0d0a


According to MS on 5/9/2007 8:05 AM:
> Hello,
> 
> Versions : 
> 
> i tried M4 1.4 and M4 1.4.7 which both shows the problem
> M4 1.4.4 do not show the problem, but i cannot see a comment, that something
> is fixed in this area

Thanks for the report.  Which platform are you running on (cygwin with
text mounts, mingw, or other)?  I'm assuming it's windows-based and text
file related, since I can't reproduce it on cygwin with binary mounts; I
also suspect that the bug you are seeing is not in m4 proper but in the
stdio library of your platform.  But m4 should still be able to work
around the bug, if possible.  I'm hoping to release m4 1.4.10 once gnulib
is able to work around the known bugs in cygwin's fseeko and mingw's
ftell, and hopefully that will fix the bug for you.

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

Eric Blake             ebb9 <at> byu.net
Permalink | Reply | 0 comments |
headers
Daniel Richard G. | 11 May 2007 06:21
Picon

[sr #105855] Multi-op patsubst() and translit()


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

                 Summary: Multi-op patsubst() and translit()
                 Project: GNU M4
            Submitted by: iskunk
            Submitted on: Friday 05/11/2007 at 04:21
                Category: None
                Priority: 5 - Normal
                Severity: 1 - Wish
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
        Operating System: GNU/Linux

    _______________________________________________________

Details:

A wish for m4 2.0: patsubst() and translit() builtins that can do more than
one operation in a single call. Right now, it's awkward to chain together
multiple invocations of these, and the quoting/robustness issues can get very
hairy.

I'd like to see patsubst()/translit() gain a multi-argument semantic like
ifelse(), where one could invoke e.g.
(Continue reading)

Permalink | Reply | 501 comments |
headers
MS | 11 May 2007 12:30

AW: M4 buffering problem? 0d0a -> 0d0d0a


Eric,

>> i tried M4 1.4 and M4 1.4.7 which both shows the problem
>> M4 1.4.4 do not show the problem, but i cannot see a comment, that
>> something is fixed in this area
> 
> Thanks for the report.  Which platform are you running on (cygwin with
> text mounts, mingw, or other)?  I'm assuming it's
> windows-based and text

its windows based. (i am running W2K, and i tried it on a XP machine too). 
at first the problem occured with m4 1.4 and cygwin1.dll from Cygnus 1.1.7.

> file related, since I can't reproduce it on cygwin with
> binary mounts; I
> also suspect that the bug you are seeing is not in m4 proper
> but in the
> stdio library of your platform.

i have one environment and i switch just m4.exe from 1.4.0 to 1.4.4. and the
problem is gone.

i am using:

S:\TOOLS\C>where cygwin1.dll
25.02.02 18:16  769352 E:\LcDevInst\BIN\cygwin1.dll

this is a copy from:
(Continue reading)

Permalink | Reply | 501 comments |
headers
Eric Blake | 11 May 2007 14:17
Gravatar

Re: AW: M4 buffering problem? 0d0a -> 0d0d0a


According to MS on 5/11/2007 4:30 AM:
> its windows based. (i am running W2K, and i tried it on a XP machine too). 
> at first the problem occured with m4 1.4 and cygwin1.dll from Cygnus 1.1.7.

I _highly_ suggest updating your cygwin installation.  Cygwin1.dll is now
at 1.5.24, and I maintain the cygwin port of m4, which is at m4 1.4.9.
Anything older than that has known bugs, so I am not willing to spend time
helping you debug obsolete setups.  I also recommend that you ask on the
cygwin mailing list (cygwin AT cygwin DOT com) rather than here, since
your problem is cygwin-specific.

> 
> a few days ago i installed MSYS1.0 and tried it in this environment with the
> same result.

I'm less familiar with an MSYS environment, but I know the msys project
forked from cygwin, but tends to use mingw binaries.  The mingw port of m4
uses Microsoft's stdio instead of cygwin's.  I know that Microsoft's stdio
is buggy on text files, and am trying to find time to help gnulib work
around that, but I don't think the bugs are the same.  But are you sure
you weren't just using msys as the shell, but still getting the behavior
of the cygwin m4?

> e:\temp on /tmp type user (textmode)
> c: on /cygdrive/c type user (binmode,noumount)

Was your input file in /tmp, perchance, since that is your only text
mount?  I suggest sticking with binary mounts if you are going to use cygwin.
(Continue reading)

Permalink | Reply | 501 comments |
headers
Eric Blake | 11 May 2007 14:33
Picon

[sr #105855] Multi-op patsubst() and translit()


Follow-up Comment #1, sr #105855 (project m4):

Why can't you write your own recursive macro that does this?  translit should
be easy:

# translit(string, regex1, replace1, regex2, replace2, ...)
changequote([,])
pushdef([translit], [ifelse(eval([$# <= 3]), 1,
  [builtin([translit], $ <at> )],
  [translit(builtin([translit], [$1], [$2], [$3]),
     shift(shift(shift($ <at> ))))])])

patsubst is a bit harder, since 2.0 is adding the optional resyntax parameter
(you almost need to reverse the argument order, and specify the resyntax
parameter before the list, since it is difficult in recursive algorithms to
get the last argument on the first iteration of action), but still something
you should be able to write a wrapper for.  I'm not sure I see modifying the
builtin to do this, if we can't prove that there is an efficiency issue that
can't be worked around by merely writing wrappers around the existing
builtins.

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via/by Savannah
(Continue reading)

Permalink | Reply | 502 comments |
headers
MS | 11 May 2007 15:58

AW: AW: M4 buffering problem? 0d0a -> 0d0d0a

Eric Blake wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> According to MS on 5/11/2007 4:30 AM:
>> its windows based. (i am running W2K, and i tried it on a XP machine
>> too). at first the problem occured with m4 1.4 and cygwin1.dll from
>> Cygnus 1.1.7. 
> 
> I _highly_ suggest updating your cygwin installation.
> Cygwin1.dll is now
> at 1.5.24, and I maintain the cygwin port of m4, which is at m4 1.4.9.
> Anything older than that has known bugs, so I am not willing
> to spend time
> helping you debug obsolete setups.  I also recommend that you
> ask on the
> cygwin mailing list (cygwin AT cygwin DOT com) rather than here, since
> your problem is cygwin-specific.

can you tell me what i should download (and from where) and install to test
in this environment?
i tried to download m4 1.4.9 but this does not work with my cygwin1.dll.

ftp://gd.tuwien.ac.at/gnu/gnu-win32/release/m4

error : procedure entry point __getreent missing in cygwin1.dll

> 
>> 
>> a few days ago i installed MSYS1.0 and tried it in this environment
(Continue reading)

Permalink | Reply | 1 comment |
headers
Matthew Woehlke | 11 May 2007 17:13
Picon
Gravatar

Re: M4 buffering problem? 0d0a -> 0d0d0a

MS wrote:
> Eric Blake wrote:
>> According to MS on 5/11/2007 4:30 AM:
>>> its windows based. (i am running W2K, and i tried it on a XP machine
>>> too). at first the problem occured with m4 1.4 and cygwin1.dll from
>>> Cygnus 1.1.7. 
>> I _highly_ suggest updating your cygwin installation.
>> Cygwin1.dll is now
>> at 1.5.24, and I maintain the cygwin port of m4, which is at m4 1.4.9.
>> Anything older than that has known bugs, so I am not willing
>> to spend time
>> helping you debug obsolete setups.  I also recommend that you
>> ask on the
>> cygwin mailing list (cygwin AT cygwin DOT com) rather than here, since
>> your problem is cygwin-specific.
> 
> can you tell me what i should download (and from where) and install to test
> in this environment?
> i tried to download m4 1.4.9 but this does not work with my cygwin1.dll.

To quote Eric: "I _highly_ suggest updating your cygwin installation." 
Go to www.cygwin.com, download setup.exe, and use that to update 
everything you have installed. Note that bug-m4 is not an appropriate 
list for help updating a Cygwin installation.

It is not surprising that recent m4 binaries do not work with ancient 
versions of cygwin1.dll.

p.s. it would be great if you could fix your mailer to use the standard 
'Re:' prefix when replying instead of 'AW:' which confuses (at least)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Richard G. | 12 May 2007 03:39
Picon

[sr #105855] Multi-op patsubst() and translit()


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

(typeytype in the new-and-improved translit macro)
=>
translit([abc123], [[a-z]], [[A-Z]], [[0-4]], [[5-9]])
=> ABC678
translit([abc)123], [[a-z]], [[A-Z]], [[0-4]], [[5-9]])
=> /opt/m4/bin/m4:stdin:7: Warning: translit: too few arguments: 1 < 2
ABC123,
     [0-4],[5-9])

Robustness against meta-characters was the issue for me.

I didn't go so far as to try a recursive macro, but there were two other
approaches I was experimenting with. First, iteratively operating on a
temp-variable macro...

pushdef([tmp], [$1])
define([tmp], patsubst(tmp, [pat1], [rep1]))
define([tmp], patsubst(tmp, [pat2], [rep2]))
...
tmp
popdef([tmp])

Second, just nesting the patsubst() calls:

patsubst(patsubst(patsubst([$1], [pat1], [rep1]), [pat2], [rep2]), ...)

The problem with all these approaches is in quoting the text argument to
(Continue reading)

Permalink | Reply | 1 comment |

Gmane