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
39  2765 
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.
CBFalconer <cb********@yahoo.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_Keith) 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"
Keith Thompson wrote:
CBFalconer <cb********@yahoo.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.
CBFalconer <cb********@yahoo.comwrites:
Keith Thompson wrote:
>CBFalconer <cb********@yahoo.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.
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_Keith) 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"
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
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
On Aug 14, 9:55 am, Richard Heathfield <r...@see.sig.invalidwrote:
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
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@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?
CBFalconer wrote:
Keith Thompson wrote:
>CBFalconer <cb********@yahoo.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:
....
>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.
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
Keith Thompson wrote:
CBFalconer <cb********@yahoo.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.
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.
mathieu wrote:
CBFalconer <cbfalco...@yahoo.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.
On Thu, 14 Aug 2008 07:31:46 +0000, Richard Heathfield
<rj*@see.sig.invalidwrote:
>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.
Would that everyone followed that policy, even me.
Richard Harter, cr*@tiac.net http://home.tiac.net/~cri, http://www.varinoma.com
Save the Earth now!!
It's the only planet with chocolate.
CBFalconer wrote:
Keith Thompson wrote:
>CBFalconer <cb********@yahoo.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.
CBFalconer <cb********@yahoo.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_Keith) 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 <ma***************@gmail.comwrites:
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.
--
Keith Thompson (The_Other_Keith) 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"
In article <-4******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:
....
>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!
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.
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.
On 14 Aug 2008 at 17:21, Kenny McCormack wrote:
Richard Heathfield <rj*@see.sig.invalidwrote:
[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.
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.
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.invalidwrote:
[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.
On Aug 14, 6:48*pm, Keith Thompson <ks...@mib.orgwrote:
mathieu <mathieu.malate...@gmail.comwrites:
* 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_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.
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.thatotherlanguage or
comp.lang.thatotherlanguage.moderated 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
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
mathieu <ma***************@gmail.comwrites:
On Aug 14, 6:48*pm, Keith Thompson <ks...@mib.orgwrote:
[...]
><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>
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_Keith) 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"
On Aug 14, 10:23*pm, Keith Thompson <ks...@mib.orgwrote:
[...]
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 GetModuleFileName (win32) and /proc/self/exe (proc
system), but this is again something with lots of #ifdef not easily
portable.
</OT #2>
-Mathieu ja*********@verizon.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();
decidewheretogonext();
}
else {
alliswellwithnewfunct();
...
}
It may be a pain in the butt to write 'cleanupwhatever' and
'decidewheretogonext'. 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.
CBFalconer <cb********@yahoo.comwrites:
[...]
It may be a pain in the butt to write 'cleanupwhatever' and
'decidewheretogonext'. 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_Keith) 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"
CBFalconer wrote:
ja*********@verizon.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();
decidewheretogonext();
}
else {
alliswellwithnewfunct();
...
}
It may be a pain in the butt to write 'cleanupwhatever' and
'decidewheretogonext'. There is no problem replacing the calls to
exit with returning something, since the OP obviously has the
source code.
He didn't tell us how many different functions there were that called
exit(). He also didn't tell us how many different places in the program
that those functions are called from. However, if he's seriously
considering a myexit() function which calls longjmp(), I suspect that
there are probably at least a dozen such calls. If I understand what
you're suggesting properly (which is far from clear), he'll have to
figure out, at almost every place on the call chain connecting main() to
exit(), what the equivalent of cleanupwhatever(), decidewheretogonext()
and alliswellwithnewfunct() should be; in general, it will be different
at each of those locations.
It's certainly possible (I just recently got through doing something
similar), but I don't see how it can be described as "easy".
CBFalconer wrote:
mathieu wrote:
>CBFalconer <cbfalco...@yahoo.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.
I don't quite follow the point of your criticism. The exit() calls were
not put into the code by mathieu. He's trying to figure out what to
replace them with. What did he say to make you think he didn't
understand how exit() works? Are you assuming that the exit() calls are
coming from within main() itself? That's the only way I can make your
objections seem to make sense, but I can't figure out why you'd assume that.
James Kuyper wrote:
CBFalconer wrote:
>mathieu wrote:
>>CBFalconer <cbfalco...@yahoo.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.
I don't quite follow the point of your criticism. The exit()
calls were not put into the code by mathieu. He's trying to
figure out what to replace them with. What did he say to make
you think he didn't understand how exit() works? Are you
assuming that the exit() calls are coming from within main()
itself? That's the only way I can make your objections seem to
make sense, but I can't figure out why you'd assume that.
I didn't criticize, at least I don't think so. I made suggestions
about how to perform his port. If some of my assumptions about the
(never shown) code he wants to replace are false, then some of the
suggestions are pure blooey.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
On Aug 15, 8:26*am, CBFalconer <cbfalco...@yahoo.comwrote:
James Kuyper wrote:
CBFalconer wrote:
mathieu wrote:
CBFalconer <cbfalco...@yahoo.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.
I don't quite follow the point of your criticism. The exit()
calls were not put into the code by mathieu. He's trying to
figure out what to replace them with. What did he say to make
you think he didn't understand how exit() works? Are you
assuming that the exit() calls are coming from within main()
itself? That's the only way I can make your objections seem to
make sense, but I can't figure out why you'd assume that.
I didn't criticize, at least I don't think so. *I made suggestions
about how to perform his port. *If some of my assumptions about the
(never shown) code he wants to replace are false, then some of the
suggestions are pure blooey.
As I said before it's is called 'PVRG JPEG 1.2.1' you can google for
it. Or see my integration in GDCM: http://gdcm.svn.sourceforge.net/view...tilities/pvrg/
And yes there are *plenty* of exit all over the place (read: in
functions other than the original 'main').
$ grep exit\( * | wc
75 152 2479
Which are spread in different files:
$ grep -l exit\( * | wc
8 8 68
And no this code is not easy to follow (slightly easier to follow than
IJG, since less complex)
-M
CBFalconer wrote:
James Kuyper wrote:
>CBFalconer wrote:
>>mathieu wrote:
....
>>>Thanks I also know how to read the man page of exit :)
That wasn't clear to me. ...
....
I didn't criticize, at least I don't think so.
I think that the your comment cited above sounds fairly critical.
... I made suggestions
about how to perform his port. If some of my assumptions about the
(never shown) code he wants to replace are false, then some of the
suggestions are pure blooey.
He gave us a link to the code at <http://gdcm.sourceforge.neton Thu,
14 Aug 2008 13:53:51 -0700 (PDT).
I don't know for sure what assumptions you made, but it has seemed to me
during this discussion that your comments made sense only if you were
assuming that all of the exit() calls were from within main(). I don't
think that assumption was ever plausible, given that his very first
message asked about the feasibility of solving his problem by replacing
exit() with longjmp(). That he asked that question doesn't prove that
exit() was being called from a subroutine - but it does make it pretty
likely. If he was just thinking about about using longjmp() to move
around main() itself, then replacing setjmp() with a statement label,
and longjmp() with a 'goto' would be a lot simpler.
mathieu wrote:
CBFalconer <cbfalco...@yahoo.comwrote:
>James Kuyper wrote:
>>CBFalconer wrote:
mathieu wrote:
CBFalconer <cbfalco...@yahoo.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.
I don't quite follow the point of your criticism. The exit()
calls were not put into the code by mathieu. He's trying to
figure out what to replace them with. What did he say to make
you think he didn't understand how exit() works? Are you
assuming that the exit() calls are coming from within main()
itself? That's the only way I can make your objections seem to
make sense, but I can't figure out why you'd assume that.
I didn't criticize, at least I don't think so. I made
suggestions about how to perform his port. If some of my
assumptions about the (never shown) code he wants to replace
are false, then some of the suggestions are pure blooey.
As I said before it's is called 'PVRG JPEG 1.2.1' you can google
for it. Or see my integration in GDCM:
http://gdcm.svn.sourceforge.net/view...tilities/pvrg/
And yes there are *plenty* of exit all over the place (read: in
functions other than the original 'main').
$ grep exit\( * | wc
75 152 2479
Which are spread in different files:
$ grep -l exit\( * | wc
8 8 68
And no this code is not easy to follow (slightly easier to follow
than IJG, since less complex)
My reaction is UGH. I suspect writing your function from scratch
will be easier.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
James Kuyper wrote:
CBFalconer wrote:
>James Kuyper wrote:
>>CBFalconer wrote:
mathieu wrote:
...
>>>>Thanks I also know how to read the man page of exit :)
That wasn't clear to me. ...
...
>I didn't criticize, at least I don't think so.
I think that the your comment cited above sounds fairly critical.
Good lord. You consider "That wasn't clear to me." to be
critical? I am amazed.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
CBFalconer wrote:
James Kuyper wrote:
>CBFalconer wrote:
>>James Kuyper wrote:
CBFalconer wrote:
mathieu wrote:
...
>>>>>Thanks I also know how to read the man page of exit :)
That wasn't clear to me. ...
...
>>I didn't criticize, at least I don't think so.
I think that the your comment cited above sounds fairly critical.
Good lord. You consider "That wasn't clear to me." to be
critical? I am amazed.
That depends upon the thing you're not clear about. In this case, you
were not clear about whether he had basic reading skills and a
sufficiently strong understanding of C to use those reading skills to
understand the man page for exit(). In this group, suggesting that
someone might be lacking such elementary skills constitutes criticism,
at least, even if it doesn't quite qualify as an outright insult.
Someone who's even thinking about using longjmp() had better have a much
higher skill level than that.
On 15 Aug 2008 at 13:54, James Kuyper wrote:
CBFalconer wrote:
[same old same old]
In this case, you were not clear about whether he had basic reading
skills and a sufficiently strong understanding of C to use those
reading skills to understand the man page for exit().
Maybe CBF just assumes everyone else has the same problems he obviously
does with basic reading comprehension.
On Thu, 14 Aug 2008 09:48:44 -0700, Keith Thompson <ks***@mib.org>
wrote:
mathieu <ma***************@gmail.comwrites:
I am trying to reuse a piece of code that was designed as an
application. The code is covered with 'exit' calls. <snip>
Keeping it as a separate program and invoking it with system() might
be your best bet. <snip>
On the evidence seen so far, concur.
<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>
That will give you the nonlocal jump -- like setjmp/longjmp already
discussed, in a slightly nicer form -- but it won't help clean up
resources allocated the C way (malloc, fopen, etc.), which the
existing code presumably uses given it is C. You would have to convert
to OL-style 'RAII' manager classes. And rewriting the now-library to
that extent is almost certainly more work than just rewriting it in
library-friendly C.
- formerly david.thompson1 || achar(64) || worldnet.att.net This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: lord.zoltar |
last post by:
How can I prevent the big close button in the top of the window from
closing the window?
I want to have and "are you sure?" confirmation so the user must press
"Yes" before the program ends. Right...
|
by: lovecreatesbea... |
last post by:
Is the following code (without any code at lines x and x + 3) correct?
Is it better to call exit() or re-throw the exceptions at line x and
line x + 3?. What is the better code should we place at...
|
by: Stefan Bellon |
last post by:
Hi all!
I am embedding Python into a GUI application in a way that the GUI is
scriptable using Python.
Now I have come to a problem that when the user puts a "sys.exit(0)"
into his script to...
|
by: Marty |
last post by:
I need to catch exceptions thrown by programs started by the os.system function,
as indicated by a non-zero return code (e.g. the mount utility). For example,
if I get the following results in a...
|
by: Karlo Lozovina |
last post by:
I'm not sure if Python can do this, and I can't find it on the web. So,
here it goes:
try:
some_function()
except SomeException:
some_function2()
some_function3()
...
| | |
by: titanandrews |
last post by:
Hi All,
Is there any way to catch the exit code from someone calling
exit(status) and check the value before the program terminates?
Just for an idea, the code I'm thinking of is something...
|
by: Anthony P. |
last post by:
Hello Everyone,
I am writing a Windows Mobile 5.0 application using VS 2..8 in VB.NET.
When someone clicks the "Exit" menu option, which generates a
button_click() event, I find it easy to...
|
by: cmdolcet69 |
last post by:
I have the below if statement, that should catch if any of the
conditions are met.....however for some reasons if my
boolDSIFlushGapReading = true and MuxClass.DSIValues.count =1 and my...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
| | |
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| |
