[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFE: add md5sum as a built-in

From: Eric Blake
Subject: Re: RFE: add md5sum as a built-in
Date: Thu, 27 May 2010 12:07:42 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100430 Fedora/3.0.4-3.fc13 Lightning/1.0b1 Mnenhy/0.8.2 Thunderbird/3.0.4

On 05/26/2010 07:22 PM, Bruno Haible wrote:
> Hi,
> It would be useful to have md5sum as a built-in macro in m4.
> For example,
>   md5sum(`frankie goes to hollywood') => 5b8a258083161281a1ad2c25d1505856

It would make more sense to have an entire loadable module of various
checksum algorithms (CRC, md5sum, sha1sum, sha256sum, ...), as part of
the (eventual) m4 2.0 release that supports loadable modules.  But I'm
rather hesitant to add just one hash algorithm to the core set of
builtins for the current m4 1.4.

The other thing to consider is that even if m4 supports it right now, it
will be years before you could rely on its existence from within
autoconf/automake, unless you are able to write a replacement hash
algorithm using existing m4 constructs.  If you do get a replacement
hash written in m4, then you can use it in autoconf without having to
change m4 proper, at which point the idea of a loadable module that
provides the hash as an extended builtin for speed is even more
appealing, all without changing the set of core builtins.

> In theory it would be possible to use the 'esyscmd' built-in. But that's
> likely too slow when you use the function in a number of places. (For
> my first use-case, there would be 300 invocations when autoconf is asked
> to process a particular, real-life configure.ac file.)

What exactly are you trying to achieve?  Maybe there is an alternative
algorithm that would still let you do collision detection, without
having to do full-blown hashing.  The autoconf notion of m4_set is a
rather powerful example of using multiple m4_defines within a
well-isolated namespace of macro names in order to avoid collisions
within a set, and it shouldn't be too hard to expand it into a key/value
map rather than it's current use of O(1) key lookup.

Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]