Document Number: WG14 N600/X3J11 96-064 C9X Revision Proposal ===================== Title: Stack Overflow Checking Author: Konstantin V. Galichsky Author Affiliation: SC PHYSICON, Ltd. Postal Address: Moscow, Russia E-mail Address: kg@scph.mipt.ru Telephone Number: Fax Number: Sponsor: Date: September 9th, 1996 Document History: none Proposal Category: __ Editorial change/non-normative contribution __ Correction XX New feature __ Addition to obsolescent feature list __ Addition to Future Directions __ Other (please specify) ______________________________ Area of Standard Affected: __ Environment XX Language __ Preprocessor XX Library __ Macro/typedef/tag name __ Function __ Header __ Other (please specify) ______________________________ Prior Art: _________________________________________________ Target Audience: all Related Documents (if any): ________________________________ Proposal Attached: XX Yes __ No, but what's your interest? It is not specified in ANSI C what is to be performed by every C/C++ environment after the stack overflow (SO). This makes some recursive algorithms unsafe in sence that the programmer has no way even to report the user about the reasons (invalid parameters and so on) of the SO occured. My proposal is following: the programmer may specify two things in a program: 1) to define the function to be called on SO (SO-handler), 2) to explicitly specify 'dangerous' places by call of special SO-checking standard library function. It is important to keep in mind that there are realizations of C which can check SO only by adding special code in the beginning of EVERY function. This means the performance will be lost. So, the possibility to check SO 'everytime' must be optional, as in the existing realizations. That's why it is important to give the programmer the chance to explicitly call SO-checker in the beginning of dangerous (recursive, prone to SO) functions. Again, the realizations with system-level (hardware or software) SO-checking may implement the SO-checker as empty macro as they are tracing SO everytime. So, the environment must guarantee that by explicit or implicit SO detection in 'dangerous' functions the SO-handler will be called. And, optionally, it may detect SO always. A program may use library SO-handler 'by default' (it may simply call abort()), or report the user about reasons of termination and terminate, or perform long jump and continue to work. In C++, SO-handler may throw special library exception. Possibly, an additional header file should be added into the standard library to declare the prototypes. // checkso.h typedef void (* so_handler) (void); so_handler set_so_handler (so_handler); void check_stack_overflow (); // checkso.cpp # include # include static void standard_so_handler (void) { abort (); } static so_handler current_so_handler = standard_so_handler; so_handler set_stack_handler (so_handler soh) { so_handler prev_soh = current_so_handler; current_so_handler = soh ? soh : standard_so_handler; return soh ? prev_so_handler : standard_so_handler; } void check_stack_overflow () { // Realization-dependant implementation. // ... } // Example of user code. # include # include int fact (int n) { check_stack_overflow (); return n ? n*fact (n-1) : 0; } void my_sh () { printf ("To big value given\n"); abort (); } void foo (void) { so_handler old_soh = set_so_handler (my_sh); fact (100000); set_so_handler (old_soh); }