Re: func_arith and func_len

[Ralf Wildenhues]

Hello Roland,

* Roland Mainz wrote on Sat, Apr 19, 2008 at 11:46:02PM CEST:
> On 4/19/08, Ralf Wildenhues <address@hidden> wrote:
> > [ <http://lists.gnu.org/archive/html/libtool-patches/2008-04/msg00096.html> 
> > ]

> [snip]
> >  2008-04-19  Ralf Wildenhues  <address@hidden>
> >
> >         Exploit shell arithmetic expansion and ${#var}.
[...]
> >         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 ?

Yes.  The diff -u is in the link that I quoted at the beginning.

> 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

Sorry, but: first, there is no floating point in either Libtool, nor
Posix shell semantics.  Second, if you can prove to me (by posting
timing comparisons) that conversion from integer to string or vice
versa, has *any* performance impact whatsoever on Libtool, I'll gladly
send lots of beer your way.  I mean hey, we still fork quite a bit, and
you can probably solve a cheap differential equation during the time
that one fork takes even on sane systems like Linux.

No really, nothing of that sort of questions even remotely applies to
Libtool.

Cheers,
Ralf