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

[Antoninus Twink]

Re: catching exit

On 13 Aug 2008 at 21:33, CBFalconer wrote:

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'.
>>

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]

Re: catching exit

CBFalconer <cbfalconer@yah oo.comwrites:

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.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[CBFalconer]

Re: catching exit

Keith Thompson wrote:

CBFalconer <cbfalconer@yah oo.comwrites:

>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.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

[Keith Thompson]

Re: catching exit

CBFalconer <cbfalconer@yah oo.comwrites:

Keith Thompson wrote:

>CBFalconer <cbfalconer@yah oo.comwrites:

>>mathieu wrote:
>>>
>>>I am trying to reuse a piece of code that was designed as an
>>>applicatio n. 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?

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Heathfield]

Re: catching exit

CBFalconer said:

Keith Thompson wrote:

<snip>

>>
>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.

No, it's the original question. 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.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

Re: catching exit

mathieu said:

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 ?

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?

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[mathieu]

Re: catching exit

On Aug 14, 9:55 am, Richard Heathfield <r...@see.sig.i nvalidwrote:

mathieu said:
>

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 ?

>
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]

Re: catching exit

In article <lntzdo13mu.fsf @nuthaus.mib.or g>,
Keith Thompson <kst-u@mib.orgwrote in a splendid little chick fight
leading up to:
....

>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]

Re: catching exit

CBFalconer wrote:

Keith Thompson wrote:

>CBFalconer <cbfalconer@yah oo.comwrites:

>>mathieu wrote:
>>>
>>>I am trying to reuse a piece of code that was designed as an
>>>applicatio n. 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:

....

>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.

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.

[Richard Heathfield]

Re: catching exit

mathieu said:

<snip>

So to paraphrase you, I should

s/should/could/

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...

Yes - it's the same problem, just in a slightly different form.

I am not very keen on 'system' call, as I do not know how
portable they are.

The function itself is portable, insofar as any hosted implementation is
required to support the call - but the meaning of the return value is
implementation-defined (unless you pass it NULL, in which case the value
is 0 if there is NO command processor available, otherwise non-zero), and
of course the semantics of the executed command depends on the system -
for example, system("PAUSE") is well-defined on Windows, but pretty
meaningless on Linux (unless you happen to have a program in your path
named PAUSE, which of course might be a video game, or a word processor,
or anything, really).

So yes I am stuck on reusing this piece of code,
and my goal is to spent little time as possible.

Then system() is probably the way to go - but of course you'll need to
ensure that the command that you invoke has the identical meaning in all
relevant ways on all target systems.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[CBFalconer]

Re: catching exit

Keith Thompson wrote:

CBFalconer <cbfalconer@yah oo.comwrites:
>

.... snip ...

>

>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?

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'.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

[CBFalconer]

Re: catching exit

James Kuyper wrote:

>
CBFalconer wrote:
>

.... snip ...

>

>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.

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

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

[CBFalconer]

Re: catching exit

mathieu wrote:

CBFalconer <cbfalco...@yah oo.comwrote:

>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:

>

.... 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.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

[Richard Harter]

Re: catching exit

On Thu, 14 Aug 2008 07:31:46 +0000, Richard Heathfield
<rjh@see.sig.in validwrote:

>CBFalconer said:
>

>Keith Thompson wrote:

><snip>

>>>
>>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.

>
>No, it's the original question. 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
>embarrassmen t.

Would that everyone followed that policy, even me.


Richard Harter, cri@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
Save the Earth now!!
It's the only planet with chocolate.