2014-08-28 12:08 GMT-07:00 Eric Blake <ebl...@redhat.com>: > On 08/28/2014 12:49 PM, bogun.dmit...@gmail.com wrote: > > > If follow this logic - we shoul try to catch incorrect user behaviour... > we > > will got errors/signals from kernel. > > > > Simple situation: > > $ ((1/0)) > > bash: ((: 1/0: division by 0 (error token is "0") > > > > Whey there is check on division by zero? We can predict this? - No. But > we > > can detect it... and we out nice, detailed error message. > > Actually, division by zero is fairly easy to check, and this is probably > a case where bash is checking for division by 0 up front rather than > handling SIGFPE after the fact. > Is it so heavy to check length of $BASH_SOURCE array?
> So why I should got SIGSEGV instead of nice, detailed error message in > > recursion? We can detect it? > > GNU libsigsegv proves that it is possible to detect when SIGSEGV was > caused by stack overflow. It can't help prevent stack overflow, and you > _don't_ want to penalize your code by adding checking code into the > common case (if I'm about to overflow, error out instead), but leave > stack overflow as the exceptional case (if I've already overflowed and > received SIGSEGV, convert it into a nice error message to the user > before exiting cleanly, instead of the default behavior of dumping > core). But someone would have to write the patch for bash to link > against libsigsegv. > I undestand it. It better than getting SIGSEGV, but not a solution for this issue. As I think. -- > Eric Blake eblake redhat com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org > >
