POVRay for UNIX does not exit with a non-zero exit status when an Error(..) 
occurs (such as during parsing). 

In order to fix that, the following patch is the easiest way I could come 
up with. Maybe not 100% clean (if exit codes can be >=999999): 

-----------<patch.diff>------------
diff -urN povray-3.6/unix/config.h povray-3.6-modified/unix/config.h
--- povray-3.6/unix/config.h    2004-07-18 12:16:27.000000000 +0200
+++ povray-3.6-modified/unix/config.h   2004-08-11 19:51:28.000000000 +0200
@@ -159,9 +159,9 @@
 /*
  * POVMS stuff.
  */
-#define POVRAY_BEGIN_COOPERATE  if(setjmp(globalSetJmpEnv) == 0) {
-#define POVRAY_END_COOPERATE    }
-#define EXIT_POVRAY(n)          longjmp(globalSetJmpEnv, 1)
+#define POVRAY_BEGIN_COOPERATE  int _rv=setjmp(globalSetJmpEnv); if(_rv==0) {
+#define POVRAY_END_COOPERATE    } else if(_rv!=1) throw (_rv-1000000);
+#define EXIT_POVRAY(n)          longjmp(globalSetJmpEnv, n ? (n+1000000) : 1)
 
 /*
  * Namespace.
--------------------------------------

Please consider fixing this in the next release. 

Wolfgang

Post a reply to this message

In article <411a62cc@news.povray.org> , Wolfgang Wieser 
<wwi### [at] nospamgmxde>  wrote:

> POVRay for UNIX does not exit with a non-zero exit status when an Error(..)
> occurs (such as during parsing).

One could also just call exit ... on the other hand, a clean way would
certainly be to assign the error code to a variable an return that.  Your
code certainly is not a clean solution.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:

> In article <411a62cc@news.povray.org> , Wolfgang Wieser
> <wwi### [at] nospamgmxde>  wrote:
> 
>> POVRay for UNIX does not exit with a non-zero exit status when an Error(..)
>> occurs (such as during parsing).
> 
> One could also just call exit ... on the other hand, a clean way would
> certainly be to assign the error code to a variable an return that.  Your
> code certainly is not a clean solution.
> 
Well... UNIX povray actually will never exit() but instead go though some 
longjmp into the cooperate funcion which will then return to main or throw 
some exception. It took me some time until I finally figured out what was 
actually going on here and I was really wondering if the present state 
can be called a "clean solution"...

But I'm sure, Nicolas will come up with something better. :)

Wolfgang

Post a reply to this message

Wolfgang Wieser wrote:
> Thorsten Froehlich wrote:
> 
> 
>>In article <411a62cc@news.povray.org> , Wolfgang Wieser
>><wwi### [at] nospamgmxde>  wrote:
>>
>>
>>>POVRay for UNIX does not exit with a non-zero exit status when an Error(..)
>>>occurs (such as during parsing).
>>
>>One could also just call exit ... on the other hand, a clean way would
>>certainly be to assign the error code to a variable an return that.  Your
>>code certainly is not a clean solution.
>>
> 
> Well... UNIX povray actually will never exit() but instead go though some 
> longjmp into the cooperate funcion which will then return to main or throw 
> some exception. It took me some time until I finally figured out what was 
> actually going on here and I was really wondering if the present state 
> can be called a "clean solution"...
> 
> But I'm sure, Nicolas will come up with something better. :)
> 
> Wolfgang
> 
can i assume this might have a bearing on problems found using 
emacs/xemacs pov-mode 2.10 and pov-ray 3.6

previously reported/posted and pooh-poohed(sp?) as a possible problem
istr a suggestion of contacting pov-mode author as well

oh well time for ROFL

stephen

Post a reply to this message

> But I'm sure, Nicolas will come up with something better. :)

	Honestly, I'm not sure of that, since I have myself a hard
time with those cooperate stuffs and I'm still surprised it somehow
works currently  ;-)  {well it works because Thorsten wrote the
main() and cooperate-related functions, not me}

	BTW I saw some time ago on your pages that you already had
problems with the exit code, but I simply didn't get an idea of how
to cleanly solve that.  And I don't like much the way you do it,
though I'm unable to propose anything better at the moment...

	Another BTW, there's a little glitch on the povray.org
download page, since the current UNIX version is 3.6.1 and the
corresponding sources are there:

ftp://ftp.povray.org/pub/povray/Official/Unix/povray-3.6.1.tar.gz
ftp://ftp.povray.org/pub/povray/Official/Unix/povray-3.6.1.tar.bz2

	I can also provide with diffs from 3.6 to 3.6.1, on a per
request basis.

	- NC

Post a reply to this message

In article <411a84ff@news.povray.org> , Wolfgang Wieser 
<wwi### [at] nospamgmxde>  wrote:

> Well... UNIX povray actually will never exit() but instead go though some
> longjmp into the cooperate funcion which will then return to main or throw
> some exception. It took me some time until I finally figured out what was
> actually going on here and I was really wondering if the present state
> can be called a "clean solution"...

Well, it certainly is given how the code is separated into a frontend and
backend.  It also certainly is not trivial to understand.  In short the
frontend is pure C++ while the backend has to suit C.  If you would check,
you would find that povray_exit is only called with three different
parameters (0, 1, 2) in four places.  Two signals a user about, one an
error.  So all you need to do if you desire a return value for a
command-line version (for a GUI version it does not matter) returned via
main, you either exit directly (the default macro implementation), or, if
you desire to perform proper cleanup (and displaying all other messages) you
simply return -n via the longjmp and return that.  No adding of some magic
values.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Nicolas Calimet wrote:

>> But I'm sure, Nicolas will come up with something better. :)
> 
> Honestly, I'm not sure of that, since I have myself a hard
> time with those cooperate stuffs and I'm still surprised it somehow
> works currently  ;-)  {well it works because Thorsten wrote the
> main() and cooperate-related functions, not me}
> 
After thinking about it: What about completely sending all that 
longjmp stuff to hell (grin...) and simply use: 

-----------------------------------------------------------------------------
struct ExitPovrayException
{
    int code;
    ExitPovrayException(int _c) : code(_c) {}
};

/*
 * POVMS stuff.
 */
#define POVRAY_BEGIN_COOPERATE  try {
#define POVRAY_END_COOPERATE    } catch(ExitPovrayException ex) \
                                  {  throw(ex.code);  }
#define EXIT_POVRAY(n)          throw ExitPovrayException(n);
-----------------------------------------------------------------------------

Maybe one could even get along without the ExitPovrayException and use 
the "throw (int)" construct directly: 

-----------------------------------------------------------------------------
/*
 * POVMS stuff.
 */
#define POVRAY_BEGIN_COOPERATE  /*empty*/
#define POVRAY_END_COOPERATE    /*empty*/
#define EXIT_POVRAY(n)          throw int(n);
-----------------------------------------------------------------------------

I don't have a full overview over the use of exceptions in POVRay, so 
I was trying to be careful with the first variant here. In this case one 
should probably add a further catch(ExitPovrayException ex) in main(). 
However, the second variant at least works for my simple tests. 

> BTW I saw some time ago on your pages that you already had
> problems with the exit code, but I simply didn't get an idea of how
> to cleanly solve that.  And I don't like much the way you do it,
> though I'm unable to propose anything better at the moment...
> 
I don't know exactly what you're referring to but the POVRay exit code 
issue for versions 3.1g an 3.5.. already cost me some sleepness nights 
while trying to make RendView know what to do with the output file 
(was it failure or complete? can we resume the render? etc.)...

> Another BTW, there's a little glitch on the povray.org
> download page, since the current UNIX version is 3.6.1 and the
> corresponding sources are there:
> 
Yes, actually, I noticed and upgraded just some minutes after having 
sent the initial posting. All the patches on my website are already 
against 3.6.1 :)

> ftp://ftp.povray.org/pub/povray/Official/Unix/povray-3.6.1.tar.gz
> ftp://ftp.povray.org/pub/povray/Official/Unix/povray-3.6.1.tar.bz2
> 
> I can also provide with diffs from 3.6 to 3.6.1, on a per
> request basis.
> 
Thanks for the offer. I made the diff myself using my university account. 
This reduced the download size for my slow home connection to about 12% 
of the initial size. 

Wolfgang

Post a reply to this message

In article <411a894e$1@news.povray.org> , Nicolas Calimet 
<pov### [at] freefr>  wrote:

>  Honestly, I'm not sure of that, since I have myself a hard
> time with those cooperate stuffs and I'm still surprised it somehow
> works currently  ;-)  {well it works because Thorsten wrote the
> main() and cooperate-related functions, not me}

Well, it all would be a lot easier to understand if one could think of it as
happening in two communicating threads rather than one.  Of course, this
cannot be changed for the 3.x Unix versions of POV-Ray :-)

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote:
> Well, it certainly is given how the code is separated into a frontend and
> backend.  It also certainly is not trivial to understand.  In short the
> frontend is pure C++ while the backend has to suit C.  If you would check,
> you would find that povray_exit is only called with three different
> parameters (0, 1, 2) in four places.  Two signals a user about, one an
> error.  
>
I see. At least that's a clear and resonable decision. 

> So all you need to do if you desire a return value for a 
> command-line version (for a GUI version it does not matter) returned via
> main, you either exit directly (the default macro implementation), or, if
> you desire to perform proper cleanup (and displaying all other messages) you
> simply return -n via the longjmp and return that.  No adding of some magic
> values.
> 
Well, at least the "magic number 1" needs to be added since longjmp cannot 
be used to return the value 0. This is because 0 is used as setjmp return 
value to indicate direct return (i.e. not due to a call to longjmp).

-------<manual>-------
longjmp() cannot cause 0 to be returned.  If longjmp is invoked with a 
second argument of 0, 1 will be returned instead. 
-----------------------

Wolfgang

Post a reply to this message

In article <411a97ec@news.povray.org> , Wolfgang Wieser 
<wwi### [at] nospamgmxde>  wrote:

> Well, at least the "magic number 1" needs to be added since longjmp cannot
> be used to return the value 0. This is because 0 is used as setjmp return
> value to indicate direct return (i.e. not due to a call to longjmp).

No, you need an if/else and return something positive in this case (i.e.
"1").  While not documented, you are practically promised the exit function
is only called with zero or positive values.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message