Discussion:
[ksh93u+m] Performance warning message
(too old to reply)
Janis Papanagnou
2024-10-25 04:46:05 UTC
Permalink
For this command

typeset -i indents=$(( level * indent_factor )) ###

with two integer variables, 'level' and 'indent_factor', declared
I'm getting this nice warning message

warning: line 28: indents=$(( level * indent_factor ))
is slower than ((indents= level * indent_factor ))

I thought (to avoid the warning) I'd have to split the lines like

typeset -i indents
(( indents = level * indent_factor ))

but I noticed that we can also write

(( typeset -i indents = level * indent_factor ))

(I wasn't aware about the 'typeset' command possible in arithmetic
expressions.)

Though I wonder why Ksh doesn't silently optimize the '###' marked
code since Ksh optimizes so many less obvious and much more complex
things.

Janis
Janis Papanagnou
2024-10-28 00:21:17 UTC
Permalink
Post by Janis Papanagnou
For this command
typeset -i indents=$(( level * indent_factor )) ###
with two integer variables, 'level' and 'indent_factor', declared
I'm getting this nice warning message
warning: line 28: indents=$(( level * indent_factor ))
is slower than ((indents= level * indent_factor ))
I thought (to avoid the warning) I'd have to split the lines like
typeset -i indents
(( indents = level * indent_factor ))
but I noticed that we can also write
(( typeset -i indents = level * indent_factor ))
(I wasn't aware about the 'typeset' command possible in arithmetic
expressions.)
Oops! - That's wrong. - I had just tested that only with 'ksh -n'.

ksh -n had produced the above performance warning message, but it
did not produce an error message for the (( typeset ... )) syntax,
which I saw just now when invoking the shell regularly on the code.

This is really odd (shell-)behavior! (Reporting a warning but not
an error.) - Looks like a bug to me.[*]

So we have to either use the "non-performant" syntax marked '###'
or separate the statements on two lines.
Post by Janis Papanagnou
Though I wonder why Ksh doesn't silently optimize the '###' marked
code since Ksh optimizes so many less obvious and much more complex
things.
Janis
[*] The man page says for option '-n':
"Read commands and check them for syntax errors, [...]"
So the warning message is just an undocumented feature for free?
And the 'typeset' inside the arithmetic command is syntactically
okay and deserves no diagnostic message?
Martijn Dekker
2024-11-03 17:29:02 UTC
Permalink
[...]
Post by Janis Papanagnou
Post by Janis Papanagnou
(( typeset -i indents = level * indent_factor ))
(I wasn't aware about the 'typeset' command possible in arithmetic
expressions.)
Oops! - That's wrong. - I had just tested that only with 'ksh -n'.
ksh -n had produced the above performance warning message, but it
did not produce an error message for the (( typeset ... )) syntax,
which I saw just now when invoking the shell regularly on the code.
This is really odd (shell-)behavior! (Reporting a warning but not
an error.) - Looks like a bug to me.[*]
C-style shell arithmetic is treated as mostly separate from the shell language
proper. As far as the shell language is concerned, an arithmetic expansion or
command is just a glorified quoted string. So, they are parsed separately from
the shell language, and both parsing and executing happens at runtime. This
means shell arithmetic syntax errors can only be detected while executing the
script, i.e., not when using noexec. All the POSIX-based shells are the same
in that, because they all copied ksh's design for shell arithmetic.
Post by Janis Papanagnou
"Read commands and check them for syntax errors, [...]"
So the warning message is just an undocumented feature for free?
Yes. The -n (noexec) option activates a (very limited) linter mode that
produces certain warnings. The arithmetic-related linter warnings don't look
at the arithmetic expression itself at all, but only at the shell grammar
context in which an arithmetic expression is used.
--
|| modernish -- harness the shell
|| https://github.com/modernish/modernish
||
|| KornShell lives!
|| https://github.com/ksh93/ksh
Janis Papanagnou
2024-11-03 18:59:04 UTC
Permalink
Post by Martijn Dekker
Post by Janis Papanagnou
[...]
C-style shell arithmetic is treated as mostly separate from the shell
language proper. As far as the shell language is concerned, an
arithmetic expansion or command is just a glorified quoted string. So,
they are parsed separately from the shell language, and both parsing and
executing happens at runtime. This means shell arithmetic syntax errors
can only be detected while executing the script, i.e., not when using
noexec. All the POSIX-based shells are the same in that, because they
all copied ksh's design for shell arithmetic.
Post by Janis Papanagnou
"Read commands and check them for syntax errors, [...]"
So the warning message is just an undocumented feature for free?
Yes. The -n (noexec) option activates a (very limited) linter mode that
produces certain warnings. The arithmetic-related linter warnings don't
look at the arithmetic expression itself at all, but only at the shell
grammar context in which an arithmetic expression is used.
Thanks for the background information. - I still find it strange
that structural syntactic errors are not reported but semantical
optimization warnings are. (And, as said, strange that it's not
just optimized away if the shell is even able to detect it.)

I would not have noticed if I hadn't used ksh's option -n that I
anyway use only rarely, so this discrepancy won't have an effect
on my work in practice. - Just thought it might be of interest. -
So never mind.


Concerning the original expression[*] - given that the processing
time is dominated by called processes and I/O and not by built-in
primitive math - I had kept the construct in its "non-performant"
form due to its best readability as an initialized definition.

But it bites in my eyes seeing that 'typeset -i' is declaring an
integer. So pondering about that, and remembering that Kornshell
allows integer variable use in integer contexts without using the
'$' string-value dereferencing, I just tried

typeset -i indents=level*indent_factor

and, what shall I say, it works! And it doesn't trigger a warning
if the shell is called with option '-n'.

Janis

[*] typeset -i indents=$(( level * indent_factor ))

Loading...