[Top][All Lists]

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

Re: xstrtol.h vs. gnulib-tool --pobase

From: Eric Blake
Subject: Re: xstrtol.h vs. gnulib-tool --pobase
Date: Wed, 08 Aug 2007 19:44:48 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20070728 Thunderbird/ Mnenhy/

Hash: SHA1

According to Paul Eggert on 8/8/2007 4:16 PM:
> By chance I was working in the same area.  I merged my changes into
> yours and came up with the following proposal.  It's in two parts, the
> first for gnulib and the second for coreutils (both in vc-dwim
> format).  Basically, the idea is to drop the macro STRTOL_FATAL_ERROR
> and substitute a function for it, such that the caller doesn't need to
> do memory allocation.  This also removes some of the OPT_STR_INIT
> hacks I contributed to coreutils last week.

Looks okay, except you forgot to adjust gnulib/tests/test-xstrto[iu]max.sh.

> @@ -40,19 +40,19 @@ cat > t-xstrtol.xo <<EOF
>  1->1 ()
>  -1->-1 ()
>  1k->1024 ()
> -invalid suffix in arg argument \`${too_big}h'
> -arg argument \`$too_big' too large
> -invalid arg argument \`x'
> -invalid suffix in arg argument \`9x'
> +invalid suffix in ! argument \`${too_big}h'

Also, is it safe to use ! unquoted in heredocs where the delimiter is not
escaped?  Or is there a chance that some shell will try to expand it as a
history reference?

> ===== coreutils changes =====
> * src/df.c (long_options): Don't bother prepending "--" to long
> options that OPT_STR might decode, as that hack is no longer needed.

As cute as that hack was, I'm not too upset at removing it again (I'll
have to make a similar change to m4 as this change to coreutils).

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

Eric Blake             address@hidden
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


reply via email to

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