Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #15237

Re: expression evaluation problem

Show key headers only | View raw

On 2019/07/24 10:51, Greg Wooledge wrote:
> On Wed, Jul 24, 2019 at 09:39:46AM -0700, L A Walsh wrote:
>   
>> str='cf80'
>> v=960  uxtra=1  c=0
>>     
>
> Irrelevant alias shenanigans omitted.  These are your variables. 
>   

Those aren't my variables.
If you assign the integer attribute to a variable it isn't the same
as when you don't.
>   
>> # In evaluating this expression:
>>   ((v = v | ( uxtra>=++c ? ((0x${str:2*c:2}) & 63) << (6*(uxtra-c)) : 0 )))
>>
>>
>> I get 985 and not 960 as expected
>>
>> Which only happens when 'c' is 0 in the middle 'str' expression,
>> but the ++c should increment 'c' to '1' before it is tested to be
>> less than or equal to 'uxtra'(=1).
>>     
>
> The ${str:2*c:2} part is performed first, while c is still 0, and it
> expands to "cf".
>   
---
    Why?  It isn't even necessary when 'c' is greater than 'uxtra'

> Only then does the arithmetic evaluation begin.
>   
----
    Perhaps that such evaluate happens outside of normal evaluation rules is
why shell is so slow?

> wooledg:~$ str='cf80'
> wooledg:~$ v=960  uxtra=1  c=0
> wooledg:~$ ((v = v | ( uxtra>=++c ? ((0xcf) & 63) << (6*(uxtra-c)) : 0 )))
> wooledg:~$ declare -p v
> declare -- v="975"
>
> Even with that parameter expansion out of the way, this arithmetic
> command is still ridiculously over-complicated.  I can't even guess
> what it's supposed to do.
>   
    That's because it is a fragment from a program.  It was the minimum
from that program to reproduce the problem.  It's supposed to assign 960
to 'v'.
'v' is for 'value'. 'c' is an integer counter.  uxtra is a limit.
> Have you considered performing your calculation in steps, with
> intermediate values stored in temporary variables with clear names?
> That greatly improves readability.
>   
---
    Does it improve execution time?  That's more of a concern here than
readability, since it is an expression fragment, it isn't meant to be
understood
in isolation.

    More to the point, how do I get evaluation to occur in arithmetic order?
I.e. so the string operation is done in the order the expression is
evaluated?
> Isolating the ++c into its own step would also remove all questions
> about whether the increment is performed before or after other
> calculations (or in this case, parameter expansions).  In-lining ++c
> inside a larger calculation can be OK in very simple situations, but
> a nightmare to read/understand/debug in more complex cases.
>   
    The important part for me is whether or not it is faster to perform
1 calculation, or 100.  So which would be faster?  In this case
execution speed
is more important than clarity.  I consider that a 'constraint'.

Back to gnu.bash.bug | Previous | Next | Find similar | Unroll thread

Thread

Re: expression evaluation problem L A Walsh <bash@tlinx.org> - 2019-07-24 11:43 -0700

csiph-web