"Fossies" - the Fresh Open Source Software Archive

Member "mapm_4.9.5a/DOCS/commentary.txt" (21 Feb 2010, 2680 Bytes) of package /linux/misc/old/mapm-4.9.5a.tar.gz:

    1   
    2 **************************************************************************
    3 
    4 --------------------------------
    5 COMMENTARY ON A DESIGN DECISION:
    6 --------------------------------
    7 
    8 I've had a few comments (OK, 2) about 'exit' apprearing in the library.
    9 The basic comment was that it's a bad idea ...  and I agree completely.
   10 
   11 If you use any library in a commercial application, you certainly don't
   12 want code in the library to exit on you.
   13 
   14 Here's the rationale for this library. 'exit' is ONLY called when there
   15 is a malloc/realloc failure. If the computer is low on free memory, there
   16 is not a graceful way to continue with the calculations, i.e. in a
   17 handicapped manner.
   18 
   19 At one time I looked at returning an int error type code for malloc/realloc
   20 errors. For example, this calling sequence could happen:
   21 
   22 m_apm_arctan2
   23   --> m_apm_arctan
   24      --> m_apm_arcsin
   25         --> m_apm_arccos
   26           --> M_4x_cos
   27             --> M_raw_cos
   28                --> m_apm_divide
   29                  --> m_apm_reciprocal
   30                     --> m_apm_multiply
   31                        --> M_fast_multiply
   32                           --> M_fmul_div_conq
   33                              --> M_get_stack_ptr   <<--- MALLOC FAIL HERE
   34 
   35 
   36 Returning an int error code up the chain gets real ugly, real fast.
   37 
   38 In this case, you would want m_apm_arctan2 to return the int error
   39 code, but it's not easy to get there.  Note that there are other
   40 'user callable' functions in the chain (arctan, arcsin, arccos, divide,
   41 etc) which also complicate the return code sequencing.
   42 
   43 I never came up with a good, straightforward solution (that wasn't more
   44 trouble than it was worth).
   45 
   46 If you truly want to guarantee defined behavior, I suggest the following:
   47 
   48 Compile the library with alternate malloc/realloc/free function wrappers,
   49 which can be easily accomplished by reading the comments and making the
   50 appropriate changes in m_apm_lc.h. If your app is a major "commercial"
   51 application, you likely already use your own memory management functions.
   52 
   53 These function wrappers can trap all malloc/realloc failures so the
   54 MAPM library never sees them. Then use setjmp/longjmp in these new
   55 malloc/realloc functions to handle the error yourself in the application,
   56 not in the library.
   57 
   58 The existing implementation works for 99+% of all users. For a "real"
   59 application where you truly do not want exit to be called, a simple
   60 setjmp/longjmp sequence will eliminate any malloc/realloc problems,
   61 and this also lets the application handle the error the best way for
   62 that particular application.
   63 
   64 Anyway, that's why there is (one) 'exit' in the library code.
   65 
   66 **************************************************************************
   67