Re: a recursion bug

[Bob Proulx]

Linda A. Walsh wrote:
> Steven W. Orr wrote:
> >I think there's a fundamental misunderstanding between the
> >difference of an error code returned by a system call and the exit
> >status of a process. They're two completely different things.
> ----
>       It's not a fundamental misunderstanding.  It's a fundamental belief
> in using data bandwidth and not wasting it.  If 0=ok, as it does in bash and
> with errno, and, it is the case (still is),  that errno's fit in 1 byte,
> there's no reason not to return the exact failure mode from a util...

I still think there is the misunderstanding of the OP's case between
bash and the run of it under valgrind.  I think you are still talking
about the valgrind part of the run.  But in any case, is there
anything in there that is about bash?  If so the we need an exact test
case.  If not then let's not discuss it here.

>       That's not to say that many or most do -- some even return a status
> of '0' on fatal errors (xfs_mkfile -- on running out of room returns a status 
> 0).

What xfs utils do or don't do is off topic for the bug-bash list.

> >Just for fun, look at the man page for grep. It is advertised to
> >return a 0, 1 or 2. The actual values of errno that might happen
> >in the middle are a separate problem.
> ----
>       Like I said, it's a fundamental waste of bits.
> 
>       But -- if it encountered an error, should it issue a SEGV and
> coredump message, or should it terminate the wayward script/function
> and return to the prompt?

This is just the result of "Worse is Better".  It is one of the
fundamentals that made Unix the wondeful system that we know it to be
today.  You may not like it but it is a principle that has strongly
shaped the system.

  http://en.wikipedia.org/wiki/Worse_is_better

The problem you are fighting is that every program on the system is
governed by kernel stack limits.  If the program exceeds the policy
limit then it will get a SIGSEGV for stack growth failure.

Now it is possible for a program to go to extreme efforts to trap that
case and to deal explicitly with it.  But it isn't worth it.  Worse is
better.  Better is an easy to maintain portable program.  Trying to
deal with every possible problem on every possible system in every
possible context will yield a worse solution.  Don't do it.

In the immortal words of Smith & Dale:

  SMITH: Doctor, it hurts when I do this.
  DALE: Don't do that.

>       Hey you can do whatever, but if the linux kernel crashed on every
> resource strain, most people would consider that bad.

This is a reductio ad absurdum ("reduction to absurdity") argument
that doesn't apply here.  The linux kernel was not crashing.  This is
off the topic.

Bob