C Extension - Initializers and Finalizers

[utzoo!decvax!yale-com!leichter]

This newsgroup got started to discuss proposed extensions to C.  It seems
to have gotten bogged down in detail discussions of bracketing strategies.
Herein is an attempt to return the discussion to something a bit meatier.
The following is (essentially) a man page describing an extension I added
recently to DECUS C.  It was very simple to implement and I've found it
quite useful.  (Note that this isn't yet in any distributed copies of
DECUS C; don't go off and try to find it!)

BTW:  Note the challenge in the BUGS section!
						-- Jerry
					decvax!yale-comix!leichter
					leichter @ yale
------------------------------------------------------------------------------


        1.0  Specify Initializers and Finalizers
             ------- ------------ --- ----------



                                  ***********
                                  * initial *
                                  ***********



        NAME:   initial -- Specify Initializers and Finalizers

        SYNOPSIS:

                 #include <initia.h>

                 INITIAL
                 { initial-code-block };

                 FINAL
                 { final-code-block };

        DESCRIPTION:

                The macros defined in this module provide a facility for
                module-specific  initialization  and  finalization code.
                The code in the initial-code-block is called as a normal
                C    function    before    main()    is   called;    the
                final-code-block is called on exit, just after wrapup().

                Neither call passes any arguments.

                Any number of modules  in  an  image  may  independently
                declare initializers or finalizers;  all of them will be
                called at startup or exit.  However, it is impossible to
                predict  what  order  the  calls  will  be  made in, and
                programs should not rely on any particular ordering.

                A typical use of  initializers  and  finalizers  is  the
                following:   Suppose  you  have  a package that supports
                access to some on-disk data base;  a user of the package
                will  call  a  lookup  and an update function.  The file
                containing the data  base  must  be  opened  before  any
                operations on it can take place, and it should be closed
                when the program is finished.  (Assume that the  package
                maintains  some  sort  of  resident buffer which it must
                flush.) There are two conventional approaches to solving
                this  problem:   Have  the  lookup  and update functions
                check the file on each call, and open it if necessary  -
                which  could  be  quite expensive if they are very small
                functions, and in any case does not solve the problem of
                properly  closing  the  file  - or have the main program
                call an initialization and finalization function at  the

                                                                          Page 2
        initial Specify Initializers and Finalizers


                proper  time.   The problem with this latter approach is
                lack of modularity - the main program ought not to  have
                to   know   that  the  module  needs  initialization  or
                finalization.

                The solution using these macros is straightforward.  The
                defining module includes the calls:

                        INITIAL
                        { open-the-data-base };

                        FINAL
                        { flush-buffers-and-close-the-data-base };

                Note:  Using INITIAL  will  declare  a  static  function
                named $init$(), and a (char *) named $init_;  similarly,
                FINAL will declare  $finl$()  and  $finl_.   Also,  both
                INITIAL  and  FINAL  generate  dsect  commands.  Since C
                provides no way to "remember" the  current  dsect,  both
                macros  issue  a  dsect  ""  command when they are done,
                restoring the C default dsect.

                If  a  user-written  wrapup()  function   calls   exit()
                recursively,  any  finalizers  declared  will  still  be
                called;  however, if any  finalizer  calls  exit(),  the
                program exits immediately.

        BUGS:

                Requires  the  DECUS  C  dsect  commands;   hence,  very
                non-portable.   It  may  be possible to provide the same
                functionality  using  different  techniques;   if   not,
                what's wrong with your implementation?

        AUTHOR:

                Jerry Leichter