On 6/2/22 4:00 PM, Gergely wrote:
I could not produce a scenario in 15 minutes that would indicate that
this corrupts other sections, as there is a considerable gap between the
stack and everything else. This is OS-dependent though and bash has no
control over what happens should this occur.
Because you haven't forced bash to write outside its own address space or
corrupt another area on the stack. This is a resource exhaustion issue,
no more.
Well, the issue is not the fact that this is a resource exhaustion, but
rather the fact that it's entirely OS-dependent and the programmer has
zero control over it.
The programmer has complete control over this, at least in the scenario you
reported.
What happens should the situation occur, is not up
to bash or the programmer. The behaviour is not portable and not
recoverable. A programmer might expect a situation like this, but there
is no knob to turn to prevent an abrupt termination, unlike FUNCNEST.
If you think it's more valuable, you can build bash with a definition for
SOURCENEST_MAX that you find acceptable. There's no user-visible variable
to control that; it's just not something that many people request. But it's
there if you (or a distro) want to build it in.
Speaking for myself, I'd find an error a much MUCH more palatable
condition than a segfault in this case. In the case of an error I at
least have a chance to do cleanup or emit a message, as opposed to just
terminating out of the blue. I don't think most bash programs are
written with the expectation that they might seize to run any moment
without any warning.
I think anyone who codes up an infinite recursion should expect abrupt
termination. Any other scenario is variable and controlled by resource
limits.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
