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. > > 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. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature