Re: func_arith and func_len

[Roland Mainz]

On 4/19/08, Ralf Wildenhues <address@hidden> wrote:
> [ <http://lists.gnu.org/archive/html/libtool-patches/2008-04/msg00096.html> ]
>
>  Hello Bob, Roland,
>
>  * Bob Friesenhahn wrote on Sat, Apr 19, 2008 at 05:13:13PM CEST:
>  > On Sat, 19 Apr 2008, Ralf Wildenhues wrote:
>  >
>  >> Let's reuse at_func_arith from Autotest, to redo one of the link mode
>  >> speedups that fell under the cracks a couple of years ago.
>  >>
>  >> IIRC somebody else suggested this recently, but I don't remember who.
>  >> Please speak up so I can put your name in the ChangeLog entry.
>  >
>  > Roland Mainz <address@hidden> (OpenSolaris/Ksh93 guy) is the
>  > suitable party to blame.
>
>  Thanks, Cc:ed.

... "to blame" ... for what ? :-)

[snip]
>  2008-04-19  Ralf Wildenhues  <address@hidden>
>
>         Exploit shell arithmetic expansion and ${#var}.
>         * libltdl/m4/libtool.m4 (_LT_CHECK_SHELL_FEATURES): Also check
>         for arithmetic expansion, and ${#var}.
>         (_LT_PROG_XSI_SHELLFNS): Define func_arith and func_len
>         accordingly, falling back on 'expr'
>         Note that the argument to
>         func_len may not start with a hyphen.  In the pre-Posix
>         fallback, take care not to rely on the exit status of the
>         variable assignment (not portable), but set the length to
>         $max_cmd_len instead.
>         * libltdl/config/ltmain.m4sh (func_mode_link): Use func_arith
>         and func_len throughout for integer arithmetic, fixing
>         quadratical amount of counting for reloadable object and
>         piecewise archive linking.  Change all comparisons with
>         max_cmd_len to test for smaller, non-equal length.
>         * THANKS: Update.
>         Suggested by Roland Mainz.

Erm... thanks! ... :-)
... is it possible to see the "diff -u" for the change and a shell
script code sample how the generated shell code may look like ? The
part where I am curently worrying is something like (( foo=$foo+5))
vs. (( foo=foo+5 )) - the first firm is wrong because it forces the
shell to convert the value for "foo" into a string and back after
expansion while the 2nd form avoids this mess (for integer operations
this is just a performance issue, for floating-point math the first
form leads to wrong results because the conversion to a string will
normally cause rounding errors due the base2---->base10--->base2
conversion (C99, XPG6 and ksh93 can avoid this using the
floating-point format defined by C99 (and used by printf "%a") which
uses a hexadecimal notation for floating-point values (ksh93 and all
XPG6 conformant applications should understand this format))).
The same trouble applies to stuff like foo=$((foo+5)) vs. (( foo=foo+5
)) - first form forces a conversion to a string while the 2nd one just
keeps the value for "foo" and all operations on it on the internal
variable storage.

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) address@hidden
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 7950090
 (;O/ \/ \O;)