catching exit

[santosh]

Re: catching exit

CBFalconer wrote:

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.

I thought that the original post was pretty clear about the poster's
problem.

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

No. He (the OP) is having to use a program written by someone else as a
*function* in his program. Unfortunately the program is littered with
calls to exit() which he'll obviously have to avoid if he intends to
use the program as a routine.

This sort of transformation is very difficult with a program composed of
tightly coupled routines, which were never written for independent use.

[Keith Thompson]

Re: catching exit

CBFalconer <cbfalconer@yah oo.comwrites:

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.

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 (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"

[Keith Thompson]

Re: catching exit

mathieu <mathieu.malate rre@gmail.comwr ites:

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_SUCCE SS) or an exit(EXIT_FAILU RE)
(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("existin g_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.thato therlanguage or
comp.lang.thato therlanguage.mo derated 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.

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

[Kenny McCormack]

Re: catching exit

In article <-4udnQgz4tjEQz7V nZ2dnUVZ8s7inZ2 d@bt.com>,
Richard Heathfield <rjh@see.sig.in validwrote:
....

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

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

[Antoninus Twink]

Re: catching exit

On 14 Aug 2008 at 12:10, CBFalconer wrote:

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]

Re: catching exit

On 14 Aug 2008 at 12:24, CBFalconer wrote:

mathieu wrote:

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

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

Re: catching exit

On 14 Aug 2008 at 17:21, Kenny McCormack wrote:

Richard Heathfield <rjh@see.sig.in validwrote:

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

>>(3) Now send any undeleted replies.

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.

[jameskuyper@verizon.net]

Re: catching exit

CBFalconer wrote:

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.

No, it's not that simple. Replacing

exit(status);

with

some_global = status;
return;

will not handle any of the numerous complications that have already
been mentioned elsewhere on this thread: memory leaks, files that were
not closed, at_exit() handlers (admittedly not a common problem). In
general, the kind of person who uses exit() doesn't merely ignore
memory leaks and unclosed files; such a person generally is actively
relying on exit() to handle those details. Such things can usually be
found in any program that calls exit().

Furthermore, the calling function may have been designed based upon
the assumption that the called function would only return if the
termination condition didn't come up. Since the termination condition
did come up, replacing "exit();" with "return;" may require an
extensive re-write of the calling function. Been there, done that
(quite recently) - it was not simple, it was not easy, it kept me very
busy for several days, and I finished it that quickly only because I
realized that I did not have the time I needed to perform the complete
re-design that I should properly have performed.

[Kenny McCormack]

Re: catching exit

In article <slrnga8rmt.ms8 .nospam@nospam. invalid>,
Antoninus Twink <nospam@nospam. invalidwrote:

>On 14 Aug 2008 at 17:21, Kenny McCormack wrote:

>Richard Heathfield <rjh@see.sig.in validwrote:

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

>>>(3) Now send any undeleted replies.

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

Aye - as someone else posted in one of these threads today - there is
always room for improvement.

[mathieu]

Re: catching exit

On Aug 14, 6:48 pm, Keith Thompson <ks...@mib.orgw rote:

mathieu <mathieu.malate ...@gmail.comwr ites:

  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?

Correct.

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_SUCCE SS) or an exit(EXIT_FAILU RE)
(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("existin g_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.

ok

<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.thato therlanguage or
comp.lang.thato therlanguage.mo derated will be glad to do so.
</OT>

pure genius ! I actually happen to be using this you-shall-not-name
language you are talking about. This definitely solve the issue with
the 'exit' calls. But as Eric (see early posts) mention, this is only
the visible part of the iceberg. The code is also covered with globals
that are randomly initialized in different places.

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.

alright, I am convinced.

Thanks all for your time,
-Mathieu

[Willem]

Re: catching exit

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.
)
) Comments ?

Do you have some form of fork() in your implementation ?

If so, you could fork the process and call mymain() from there, and in the
main process, wait for the exit status. This is the midway solution
between having the code in the same executable, and using system().

Depends on how portable you want the code to be, of course.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[Keith Thompson]

Re: catching exit

mathieu <mathieu.malate rre@gmail.comwr ites:

On Aug 14, 6:48 pm, Keith Thompson <ks...@mib.orgw rote:

[...]

><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.thato therlanguage or
>comp.lang.that otherlanguage.m oderated will be glad to do so.
></OT>

>
pure genius ! I actually happen to be using this you-shall-not-name
language you are talking about. This definitely solve the issue with
the 'exit' calls. But as Eric (see early posts) mention, this is only
the visible part of the iceberg. The code is also covered with globals
that are randomly initialized in different places.

Yes, there are some important points that I missed in suggesting the
"Other Language" solution. C program startup and shutdown provide
some additional functionality that you don't get in a function call.

On startup, objects with static storage duration are initialized
(explicitly or implicitly), and the standard I/O streams are opened.
On shutdown, allocated memory is *typically* deallocated (the standard
doesn't guarantee this, but it's common enough that it's likely this
program relies on it), the standard I/O streams are closed, and
probably some other stuff happens. If you turn the program into a
callable function, you'll have to perform some of these implicit
actions explicitly.

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

>
alright, I am convinced.

Good luck.

Out of curiosity, how portable does your final program need to be? If
all you need to worry about are, say, Unix-like and Windows-like
systems, dealing with the vagaries of system() shouldn't be very
difficult. If you can restrict yourself to POSIX, you're in even
better shape. If you want your code to compile and run on the DS9K,
it's going to be trickier.

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

[mathieu]

Re: catching exit

On Aug 14, 10:23 pm, Keith Thompson <ks...@mib.orgw rote:
[...]

Out of curiosity, how portable does your final program need to be?  If
all you need to worry about are, say, Unix-like and Windows-like
systems, dealing with the vagaries of system() shouldn't be very
difficult.  If you can restrict yourself to POSIX, you're in even
better shape.  If you want your code to compile and run on the DS9K,
it's going to be trickier.

It's all there: http://gdcm.sourceforge.net

So far I have only been dealing with GCC/Linux, VC/Win32 (no Win64 so
far), GCC/MacOSX. So it's not that difficult indeed... Well
theoretically.

<OT>
One of the main feature people like about this toolkit, is that it is
wrapped in Python (using swig). One of my user started using 'py2exe'
which basically gathered all the python modules + a lightweight python
interpreter in a fake executable (AFAIK). So I am now concerned that
within this py2exe executable, it would be like being in a chroot
environment and I might not even have access to a shell to execute a
system call.
But that's a different story, in a far far away newsgroup.
</OT>

<OT #2>
I am also concerned on how I am supposed to find the executable from
my python module since the exe might not be in the path. I have played
a little with GetModuleFileNa me (win32) and /proc/self/exe (proc
system), but this is again something with lots of #ifdef not easily
portable.
</OT #2>

-Mathieu

[CBFalconer]

Re: catching exit

jameskuyper@ver izon.net wrote:

CBFalconer wrote:
>

.... snip ...

>

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

>
No, it's not that simple. Replacing
>
exit(status);
with
some_global = status;
return;
>
will not handle any of the numerous complications that have already
been mentioned elsewhere on this thread: memory leaks, files that were
not closed, at_exit() handlers (admittedly not a common problem). In
general, the kind of person who uses exit() doesn't merely ignore
memory leaks and unclosed files; such a person generally is actively
relying on exit() to handle those details. Such things can usually be
found in any program that calls exit().

Yes it will, provided that the calling function does those things.
I.e. the calling code is something like:

err = newfunct(...);
if (err & BADBITS) {
cleanupwhatever ();
decidewheretogo next();
}
else {
alliswellwithne wfunct();
...
}

It may be a pain in the butt to write 'cleanupwhateve r' and
'decidewheretog onext'. There is no problem replacing the calls to
exit with returning something, since the OP obviously has the
source code.

--
[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:
[...]

It may be a pain in the butt to write 'cleanupwhateve r' and
'decidewheretog onext'. There is no problem replacing the calls to
exit with returning something, since the OP obviously has the
source code.

Are you (still!) assuming that the existing calls to exit are only
within the main function?

exit() could be called from anywhere within any function within a very
large existing program. Calling exit() terminates the program. If
the program is changed into a piece of a new larger program, keeping
the same semantics means terminating the function containing the call
to exit, and the function that called it, and the function that called
*that* function, up to *but not beyond* the function that was formerly
called "main".

Replacing the calls to exit with returning something is decidedly
non-trivial.

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