libtool-patches
[Top][All Lists]
Advanced

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

Re: func_arith and func_len


From: Ralf Wildenhues
Subject: Re: func_arith and func_len
Date: Sun, 20 Apr 2008 03:06:26 +0200
User-agent: Mutt/1.5.17+20080114 (2008-01-14)

* Bob Friesenhahn wrote on Sun, Apr 20, 2008 at 02:42:00AM CEST:
> On Sun, 20 Apr 2008, Ralf Wildenhues wrote:
>>
>> 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
>
> While for our purposes it is indeed unlikely that we can measure the  
> difference, it seems that the code should use the most "correct"
> implementation if using it requires minimal effort.

There is no "more" or "less" correct in this case.

> If all shells  
> supporting this math syntax also support the native math types (which  
> they likely do since this syntax comes from old ksh), then is there a  
> reason why we would not prefer the "native" syntax for math if we are  
> doing math?  Is there a ripple effect?

Yes.  The factoring into a shell function which supports Posix syntax
and a shell function which does the same but using expr is a lot simpler.

Apart from all this reasoning, I doubt that the shell *has* to convert
integers with (($x)); it looks like that would be a quality of
implementation issue.

Of course, Libtool doesn't used typed variables at all, they are not
Posix, and I guess factorizing that for ksh especially is not worth
the effort.  But hey, try it out and prove me wrong with your timings.

Cheers,
Ralf




reply via email to

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