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]

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]

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.

[jameskuyper]

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]

In article <sl************ *******@nospam. invalid>,
Antoninus Twink <no****@nospam. invalidwrote:

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

>Richard Heathfield <rj*@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]

On Aug 14, 6:48*pm, Keith Thompson <[e-mail] rote:

mathieu <mathieu.malate [e-mail] 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]

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]

mathieu <ma************ ***@gmail.comwr ites:

On Aug 14, 6:48*pm, Keith Thompson <[e-mail] 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) ks***@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]

On Aug 14, 10:23*pm, Keith Thompson <[e-mail] 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]

ja*********@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]

CBFalconer <cb********@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) ks***@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"