catching exit

[mathieu]

Hi there,

I am trying to reuse a piece of code that was designed as an
application. The code is covered with 'exit' calls. I would like to
reuse it as a library. For that I renamed the 'main' function into
'mymain', but I am stuck as to what I should do for the 'exit'.

AFAIK there is no portable way to catch the exit. The only thing I
can think of is atexit, but that does not work since 'exit' is still
called afterward.

What I am thinking now is that I need to replace all exit(val) with
longjmp(env, val). And make 'env' global.

Comments ?

Thanks
-Mathieu

 

[CBFalconer]

I am trying to reuse a piece of code that was designed as an
application. The code is covered with 'exit' calls. I would like
to reuse it as a library. For that I renamed the 'main' function
into 'mymain', but I am stuck as to what I should do for the
'exit'.

AFAIK there is no portable way to catch the exit. The only thing
I can think of is atexit, but that does not work since 'exit' is
still called afterward.

What I am thinking now is that I need to replace all exit(val)
with longjmp(env, val). And make 'env' global.

Just leave it calling exit. The result is as follows:

7.20.4.3 The exit function

Synopsis
[#1]
#include <stdlib.h>
void exit(int status);

Description

[#2] The exit function causes normal program termination to
occur. If more than one call to the exit function is
executed by a program, the behavior is undefined.

[#3] First, all functions registered by the atexit function
are called, in the reverse order of their registration.239)

[#4] Next, all open streams with unwritten buffered data are
flushed, all open streams are closed, and all files created
by the tmpfile function are removed.

[#5] Finally, control is returned to the host environment.
If the value of status is zero or EXIT_SUCCESS, an
implementation-defined form of the status successful
termination is returned. If the value of status is
EXIT_FAILURE, an implementation-defined form of the status
unsuccessful termination is returned. Otherwise the status
returned is implementation-defined.

Returns
[#6] The exit function cannot return to its caller.

____________________

239Each function is called as many times as it was
registered.

 

[Antoninus Twink]

Just leave it calling exit.

Brilliant.

Remind me never to use any library you write.

Oh, yes, hell would have frozen over first anyway, even without this
latest idiotic post.

 

[Keith Thompson]

Just leave it calling exit. The result is as follows:

7.20.4.3 The exit function

[C standard's description of the exit function snipped]

And how does this answer the OP's question?

He has a main program; a call to exit terminates the program.

He wants to turn this main program into a function within a larger
program. Wherever there's a call to exit, he wants to terminate the
function, not the entire (now larger) program.

 

[CBFalconer]

Just leave it calling exit. The result is as follows:

7.20.4.3 The exit function

[C standard's description of the exit function snipped]

And how does this answer the OP's question?

He has a main program; a call to exit terminates the program.

He wants to turn this main program into a function within a larger
program. Wherever there's a call to exit, he wants to terminate the
function, not the entire (now larger) program.

If that's what he wants to do that is another case. But the
previous effect was to terminate the program, whch is what exit
does.

 

[mathieu]

If you can change the source of the application, you can replace
exit() calls with myexit() calls and then do what you like, including
calling longjmp() to transfer back to a "wrapper." But that's not
likely to solve everything, unless the application has already cleaned
itself up before calling myexit(). If it hasn't, there may still be
open files and un-free()d memory hanging around ...

If the application uses atexit(), you're going to have to decide
what to do about the functions it's registered and that it thinks are
going to run when it calls exit(). Should they run even though the
application isn't really exiting? Should they run only when the whole
wrapped program exits? Either way, you've got some work to do: You'll
probably need a myatexit() that registers functions that myexit() can
run (and de-register), or a myatexit() that recognizes double-registered
functions when the wrapped application re-runs and suppresses the extra
calls to atexit(). (This carries some risk of changing the semantics,
by the way: exit() runs the functions in reverse order of registration,
so if the application registers f() and then g() the first time, but
g() and then f() the second, it's not clear what should happen.)

Yet another thing to beware of is "run-once" code that initializes
something the first time a function is called. These things often
test a local static variable inside the function to see whether this
is the first call, and your problem is to figure out which of these
should really be "run-once" and which should be "run-once per cycle,"
and to make arrangements to reset the triggers of the latter.

... and there's probably some other gotchas I haven't thought of.
This has the potential to become a very messy job indeed.

One alternative is to rewrite the code, keeping in mind that it
will be invoked multiple times in the new framework and writing
accordingly. This might be a lot of work, but it will be less work
than writing the code from scratch took (because you can study the
old code while you write the new), and it might turn out to be less
work than trying to hack the exit() calls.

Another possibility is to leave the code as it stands, and run
it as a separate program. You could use the system() function to
launch the application and wait for it to finish, possibly preparing
input files for it first and reading its output files afterward.

Changing a program's "framework" is seldom easy. Good luck!

Hi Eric,

Thanks for your input, esp. the issue with globals. This is
something I have not thought about.

As a first step, I'll replace exit with myexit+longjmp. Then as a
second step, I'll rewrite the portion that is doing the initialization
of the globals (within a func). Calling this init func will simply
reproduce the old behavior. Hopefully the library is simple enough so
that I can get rid of all leaks quickly (thanks to valgrind).

Thanks, that was very helpful !
-Mathieu

 

[mathieu]

I am trying to reuse a piece of code that was designed as an
application. The code is covered with 'exit' calls. I would like
to reuse it as a library. For that I renamed the 'main' function
into 'mymain', but I am stuck as to what I should do for the
'exit'.

AFAIK there is no portable way to catch the exit. The only thing
I can think of is atexit, but that does not work since 'exit' is
still called afterward.

What I am thinking now is that I need to replace all exit(val)
with longjmp(env, val). And make 'env' global.

Just leave it calling exit. The result is as follows:

7.20.4.3 The exit function

Synopsis
[#1]
#include <stdlib.h>
void exit(int status);

Description

[#2] The exit function causes normal program termination to
occur. If more than one call to the exit function is
executed by a program, the behavior is undefined.

[#3] First, all functions registered by the atexit function
are called, in the reverse order of their registration.239)

[#4] Next, all open streams with unwritten buffered data are
flushed, all open streams are closed, and all files created
by the tmpfile function are removed.

[#5] Finally, control is returned to the host environment.
If the value of status is zero or EXIT_SUCCESS, an
implementation-defined form of the status successful
termination is returned. If the value of status is
EXIT_FAILURE, an implementation-defined form of the status
unsuccessful termination is returned. Otherwise the status
returned is implementation-defined.

Returns
[#6] The exit function cannot return to its caller.

____________________

239Each function is called as many times as it was
registered.

Thanks I also know how to read the man page of exit

-M

 

[Keith Thompson]

mathieu wrote:

I am trying to reuse a piece of code that was designed as an
application. The code is covered with 'exit' calls. I would like
to reuse it as a library. For that I renamed the 'main' function
into 'mymain', but I am stuck as to what I should do for the
'exit'.

AFAIK there is no portable way to catch the exit. The only thing
I can think of is atexit, but that does not work since 'exit' is
still called afterward.

What I am thinking now is that I need to replace all exit(val)
with longjmp(env, val). And make 'env' global.

Just leave it calling exit. The result is as follows:

7.20.4.3 The exit function

[C standard's description of the exit function snipped]

And how does this answer the OP's question?

He has a main program; a call to exit terminates the program.

He wants to turn this main program into a function within a larger
program. Wherever there's a call to exit, he wants to terminate the
function, not the entire (now larger) program.

If that's what he wants to do that is another case. But the
previous effect was to terminate the program, whch is what exit
does.

He knew that.

If he wanted the existing exit calls to terminate the program, why
would he have asked what to do about them?

 

[mathieu]

mathieu said:






Eric has already given you some excellent advice, and there is no point in
duplicating it, obviously.

My comment is more in the nature of a smug, satisfied grin, I'm afraid. You
see, I don't use exit() - or at least, if I do, I consider it to be a bug
that has to be fixed. I've just searched my personal code base for exit()
calls. I found 24 altogether in 14 different C files (out of - well,
thousands), dating back in some cases to the mid-1990s. That's 24 bugs I
have to fix, which isn't too huge a job, really.

Why don't I use exit()? Well, it's a style thing, I suppose. I like to
think of big chunks being made up of little chunks, and that means that
little chunks have to behave like little chunks and not take arbitrary
decisions like "quit the program", leaving those decisions to bigger
chunks. And whilst I will grant a big chunk (think "main()") the right to
make such a decision, it is easy to revoke it (think "edit and rename one
function") if that big chunk becomes a mere part of an enormous chunk.

Unfortunately, it is not always possible to persuade other people of the
advantages of this kind of modularity. In 1994-5, I was working at V, and
the code I was working on was littered with mallocs, which were never
freed. (No, it wasn't me that did that, and I didn't have time to fix it
because I was too busy doing other stuff.) It was no big deal, said the
principal culprit, because the memory was in any case released when the
program exited. In due course, I left, and went on to work at W, X, and Y.
And then I was hired by Z, who had bought the code from X. And guess what?
They had to do precisely what you need to do - turn a program into a
function. And suddenly all these leaks mattered a great deal.

Fellow regulars in comp.lang.c often smile indulgently when I wax lyrical
about my strange stylistic habits - such as one entry point and one exit
point for each function and each loop, always initialise, always give
control back to your caller, and so on. But I have my reasons, and they
are good reasons. In this case: if the original programmer had been me,
your task would have been trivial, and we would never even have heard
about it because you wouldn't have had to ask.

Why am I telling you all this? Well, think about it the next time you write
a program. What if, one day, you need *this* program to become a function?
How hard would it be to do that? How can you make it easier?

So to paraphrase you, I should have said:

....
While working at X, I am trying to reuse a piece of code that was
designed by
Y as an application, in mid 1990. The code is covered with 'exit'
calls...
....



Anyway to put names, I am talking about the PVRG JPEG library (google
it if needed). And it is producing a bizarre JPEG compression for 16
bits lossless that I simply *cannot* reproduce using IJG (google). So
the only way I can support those damned lossless JPEG is to link to
PVRG. I am not very keen on 'system' call, as I do not know how
portable they are. So yes I am stuck on reusing this piece of code,
and my goal is to spent little time as possible.

-Mathieu

 

[Kenny McCormack]

....

He knew that.

If he wanted the existing exit calls to terminate the program, why
would he have asked what to do about them?

Looks like Keith is getting caught up in his own little web.

Are you guys beginning to see how pointless these little pedantic
quibbles are? How silly it looks when all you are doing is redefining
OP's questions to suit your own petty little agendas?

 

[James Kuyper]

If that's what he wants to do that is another case.

No, that's the original case, not another one.

... But the
previous effect was to terminate the program, whch is what exit
does.

And he made it abundantly clear, I thought, that the point of his
question was about not wanting to terminate the program.

 

[CBFalconer]

.... snip ...


He knew that. If he wanted the existing exit calls to terminate
the program, why would he have asked what to do about them?

Well, you read the OP post as showing more knowledge than I did.
If the original code was in the main function (which I believe it
was) it could probably have simply used 'return'.

 

[CBFalconer]

CBFalconer wrote:
.... snip ...


No, that's the original case, not another one.


And he made it abundantly clear, I thought, that the point of his
question was about not wanting to terminate the program.

Which is easy. Simply set an error flag visible in the caller, and
return. That value may be the value returned by the function.

 

[CBFalconer]

.... snip ...

Thanks I also know how to read the man page of exit

That wasn't clear to me. Since the only things you can (portably)
return from main is EXIT_SUCCESS and EXIT_FAILURE (and 0), you have
much more latitude in a function. So simply return from the
function, returning a status, and let the caller decide what to do
about it. I see no point to the exit calls. Maybe you do.

 

[Keith Thompson]

Which is easy. Simply set an error flag visible in the caller, and
return. That value may be the value returned by the function.

Yes, that *would* be easy, and again the OP probably wouldn't have
bothered to post here.

Here's the situation as I understand it.

The OP has a fairly large program, consisting of a main() function and
some number of other functions, along with whatever other external
declarations there might be. He wants to turn the whole mess into a
*library* (he actually used the word "library"). The problem is that
there are calls to exit, not just in the main() function, but in
*other* functions as well.

He wants to call the main function (now renamed to mymain) and have it
behave as it did when it was a separate program. The problem, of
course, is that a call to exit will terminate his new larger program;
to keep the same semantics, he needs it to terminate only the mymain
function.

He's already considered and rejected the use of atexit, and I think
he's currently considering setjmp/longjmp.

I figured all that out by reading the original post. I think you
could have done the same if you'd been a bit more careful.

 

[Keith Thompson]

I am trying to reuse a piece of code that was designed as an
application. The code is covered with 'exit' calls. I would like to
reuse it as a library. For that I renamed the 'main' function into
'mymain', but I am stuck as to what I should do for the 'exit'.

AFAIK there is no portable way to catch the exit. The only thing I
can think of is atexit, but that does not work since 'exit' is still
called afterward.

What I am thinking now is that I need to replace all exit(val) with
longjmp(env, val). And make 'env' global.

The real problem, I presume, is that you have exit calls from
functions other than main(). In the original version of the program,
each such call terminates the main program; in your bigger program
with main renamed to mymain, you want to terminate mymain, not your
new main. Right?

Keeping it as a separate program and invoking it with system() might
be your best bet. The behavior of system() is largely
implementation-defined, particularly its return value, but if you're
only targeting a limited number of systems you can deal with that with
a few #ifdef's.

If you want the resulting code to be portable to all conforming
systems, things are a bit more difficult. On any one system, you
should be able to tell from the result returned by system() whether
the invoked program did an exit(EXIT_SUCCESS) or an exit(EXIT_FAILURE)
(or some other system-specific value), but there's no portable way to
do that.

You'll also need to take some care to ensure that
system("existing_program") actually invokes what you want it to
invoke. The details are system-specific, but at least for Unix-like
and Windows-like systems, think about PATH settings.

<OT>
Here's another possibility. I happen to know that there's another
language, whose name is that of our local favorite language with a
couple of plus signs appended to it, which supports the kind of
control flow you're looking for. Rather than calling exit, you can
"throw" an "exception" and "catch" it at whatever level you like
rather than letting it propagate out and terminate the program. It's
not inconceivable that you could recompile this program using a
compiler for this Other Language and make use of the OL's features.
This approach could be fraught (fraught, I say!) with peril. There
are subtle differences between C and the OL, some of which may prevent
valid C code from compiling, and some of which may silently change its
behavior. And if you take that approach, we can't help you here, but
the folks over in comp.lang.thatotherlanguage or
comp.lang.thatotherlanguage.moderated will be glad to do so.
</OT>

But still, I think that system() is your best bet, requiring no
changes to the program and (probably) just a little bit of
system-specific scaffolding.

 

[Kenny McCormack]

To avoid making such mistakes in future, I recommend that you save up
your replies for an hour or so, and then:

(1) Re-read the original question, and then re-read your original reply. At
this stage, it will sometimes become clear that your reply was based on a
mis-reading of the question which your second reading makes obvious.
Solution: delete your reply without sending it.

(2) By this time, there may well be one or two other replies to the
question, by people whose opinion you respect. Read them.

If they are, in essence, the same as your own reply, delete your reply
without sending it, since it would be pointlessly duplicative (unless your
reply adds something useful that was overlooked by the others).

If they are *not* in essence the same as your reply, consider seriously the
possibility that you have mis-read the question. Read their replies, and
the original question, again, and find out why they have replied as they
did. If you genuinely interpret the question differently to them, then
edit your reply so that it says something like "I've read A's and B's
replies, and they've assumed you meant such-and-such. If so, fine. But it
seems to me that you might mean /this/ instead. If so, then my advice
is..." Then, having changed your reply, save it up for an hour or so, and
then start back at (1) again.

(3) Now send any undeleted replies.

I suggest that using this strategy could save you from a huge amount of
embarrassment.

This is a keeper. Well done, Mr. H!

 

[Antoninus Twink]

Well, you read the OP post as showing more knowledge than I did.

I think it's patently clear who's lacking knowledge here.

If the original code was in the main function (which I believe it
was) it could probably have simply used 'return'.

Your belief is incorrect, as a cursory glance at the first post in this
thread would have told you if you'd bothered to read it before getting
on your high horse and galloping a mile in the wrong direction as usual.

 

[Antoninus Twink]

That wasn't clear to me.

Well done. You've just surpassed Heathfield for the most arrogant and
patronizing post I've ever read in this newsgroup.

 

[Antoninus Twink]

Richard Heathfield <[email protected]> wrote:

[a strategy to prevent stupid posts from CBF]

This is a keeper. Well done, Mr. H!

Yes... but I'm not sure about this bit:

Of course, by this stage every single reply should have been deleted,
but just in case one slips through I'd recommend changing this to

(3) Now send any undeleted replies to /dev/null.