Address of array

Dan Franklin dan at BBN-PROPHET.ARPA
Tue Mar 25 04:51:37 AEST 1986


Even though people have said that the inconsistent treatment of arrays
and structures might be a problem from an information-hiding point of
view, they've always added that they've never run into it in practice.

I'm surprised.  I have run into the problem several times in connection
with "jmpbuf", the structure (but it's not a structure) that holds the
information communicated between setjmp and longjmp.  What I've wanted to
do in several programs is use setjmp/longjmp to signal exceptions, and
sometimes intercept the exception on its way up the stack to do cleanup in
some routine.  To do this, I make my own temporary copy of the jmpbuf.
Unfortunately, I have to know that jmpbuf is an array, not a structure,
so that I can write explicit calls to bcopy (or whatever) instead of a
simple assignment.

To give a concrete example, I might have a low-level memory allocator
interface that calls malloc() and does a longjmp() if NULL is returned;
this relieves me from the tedious and error-prone testing against NULL
everywhere I call malloc().  Then in main() I use setjmp() to set up a
handler for the exception, and print a message and exit.

But some caller of my allocator might want to gain control for some reason
to do cleanup before the program exits.  So I would like to write:

    caller()
    {
        jmpbuf temp;
    
        temp = memory_failure;      /* Wrong */
        if (setjmp(memory_failure))
        {
    	    do_cleanup();
    	    memory_failure = temp;  /* Wrong */
    	    longjmp(memory_failure, 1);
        }
    
        code_that_calls_memory_allocator;
    }

Doesn't work, of course.  I have to call bcopy instead, or invent my own
structure to put the jmpbuf into.  And this also means that no matter what
some UNIX implementor might want to put into the jmpbuf, it's got to look
(to the user) like an array, which is kind of unclean.

	Dan Franklin



More information about the Comp.lang.c mailing list