Thorsten Froehlich wrote:

> No, it is most likely just the shell that is broken (given the source of
> the
> shells in most free Unix distributions, this is hardly surprising).  
>
First of all, this is simply wrong, see below. 

But even in case it were true, it seems to me that this does not match 
the problem because the configure script is being interpreted by a shell. 

> Try 
> something like
> 
> #include <stdlib.h>
> #include <stdio.h>
> int main(int ac, char **av)
> {
>     printf("Result: %d\n", system(av[1]));
>     return 0;
> }
> 
Okay, and if you read the man page you knew the exit code of system() 
is that of wait(2) or waitpid(2) which is a plain integer storing the 
exit code in the least significant byte accessible using 
WEXITSTATUS(status). 
And the other bytes store things like the signal which killed the program. 

I just verified that the code presented by you above will NOT work as you 
expect on: 
  Darwin-PPC (MacOS-X)
  Linux-ix86
  FreeBSD-ix86
  NetBSD-ix86
  Solaris-5.9-ix86
(Nicolas: maybe I could run some checks for you on these boxes. 
I forgot that in my previous answer; but I doubt I can test cross-compiling 
using these.)

All these systems (and probably most other UNICes) behave in the way I 
described. 

> This should work and demonstrate that the system works correctly and only
> the shell is broken.  Then file a bug report at the appropriate place.
> 
OOPS... You'd better test yourself before posting :p

Wolfgang

Post a reply to this message

In article <40e6df2c@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

> I just verified that the code presented by you above will NOT work as you
> expect on:
>   Darwin-PPC (MacOS-X)
>   Linux-ix86
>   FreeBSD-ix86
>   NetBSD-ix86
>   Solaris-5.9-ix86
> (Nicolas: maybe I could run some checks for you on these boxes.
> I forgot that in my previous answer; but I doubt I can test cross-compiling
> using these.)

I assume you tried with a shell which was already pointed out as broken.
Then maybe you are just incompetent to run the test because on a FreeBSD
5.2-CURRENT as well as on Mac OS X 10.3.4 a simple program like

int main()
{
        return 12345;
}

will yield the correct result when executed by system().

> Okay, and if you read the man page you knew the exit code of system()
> is that of wait(2) or waitpid(2) which is a plain integer storing the
> exit code in the least significant byte accessible using
> WEXITSTATUS(status).

Well, given that a man-page is documentation of the state of the system you
have, not a specification, that is completely irrelevant for the correctness
of my statement.  ANSI/ISO C specifies the system function to return an
integer "int" and programs return an "int".  Neither wait nor waitpid are
part of ANSI/ISO C, they are some random Unix functions that ave nothing to
do with ANSI or ISO C.  Thus, any system that for whatever reason cannot
fulfill said specification of an international standard does not comply to
it.  It is of course nice that they document such a limitation.

As such, any such system cannot be expected to be fully supported by
POV-Ray.  Of course, that does by *no* means imply POV-Ray will not run on
such a system or that POV-Ray cannot be compiled on such a system.  The only
relevant point is that if you run on a system unable to support ANSI/ISO C,
you got the problem, not the POV-Team.

    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:

> I assume you tried with a shell which was already pointed out as broken.
> Then maybe you are just incompetent to run the test because on a FreeBSD
> 5.2-CURRENT as well as on Mac OS X 10.3.4 a simple program like
> 
No. On all systems mentioned above, I tried using the following programs: 

-----<test.c>------
#include <stdlib.h>
#include <stdio.h>
#include <sys/wait.h>
int main(int ac, char **av)
{
  int rv=system("./test2");    
  printf("Result: %x %x\n", rv,WEXITSTATUS(rv));
  return 0;
}
-----<test2.c>------
#include <stdio.h>

int main()
{
  printf("Here we are\n");
  return(0x1aa);
}
--------------------

And the result is what I described. 

> int main()
> {
>         return 12345;
> }
> 
> will yield the correct result when executed by system().
> 
This is not the case on any system I tested (Darwin-PPC, Linux-ix86,
FreeBSD-ix86, NetBSD-ix86, Solaris-5.9-ix86). 
Not even with magic number 12345 :)
You might exactly specify the system you are referring to. 

> As such, any such system cannot be expected to be fully supported by
[snipped following arrogance from Thorsten-Froehlich]

Wolfgang

Post a reply to this message

In article <40e6ece2@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

> #include <sys/wait.h>
> int main(int ac, char **av)
> {
>   int rv=system("./test2");
>   printf("Result: %x %x\n", rv,WEXITSTATUS(rv));

This is not a portable ANSI/ISO C program.  It is an operating system
specific C program:  The include file "sys/wait.h" is system specific, as is
the function/macro WEXITSTATUS.  As such, your example is specific to your
operating system, of which you already stated that it has a limitation
regarding the return value range of an ANSI/ISO C program by reading the man
page of the functions/macros you are using.  Hence, your example contributed
nothing to this discussion you did not already say.  Contrary to you, I did
provide two fully portable ANSI/ISO C programs which work exactly as I said
on the operating systems I specified.

    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:

> This is not a portable ANSI/ISO C program.  It is an operating system
> specific C program:  The include file "sys/wait.h" is system specific, as
>
This was just used to demonstrate that the actual code is the LSByte. 

I think we can stop the discussion here summing up that 






cannot be used in a configure script to determine the STDC version as 
it will not work on most or all systems it is intended to work. 

Wolfgang

Post a reply to this message

Thorsten Froehlich wrote:

> In article <40e6ae1c@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>
> wrote:
> 
>> This is probably a bad idea. It looks like __STDC_VERSION__ is
>> significantly larger than 128. Some UNIX systems use only 1 byte to store
>> the exit code of a program and hence, this will fail on these systems.
> 
> Then those systems are not compatible even with ANSI C. -- Too bad, we do
> not support such outdated systems!
> 
Maybe you could even tell us where you found this information. 

I just looked up "ANSI C Rationale 4.11", 
Section "4.10.4.5 The system function" which states:

-------------------
The system function allows a program to suspend its execution temporarily in
order to run another program to completion.  

Information may be passed to the called program in three ways: through
command-line argument strings, through the environment, and (most portably)
through data files.  Before calling the system function, the calling
program should close all such data files.  

Information may be returned from the called program in two ways: through the
implementation-defined return value (in many implementations, the
termination status code which is the argument to the exit function is
returned by the implementation to the caller as the value returned by the
system function), and (most portably) through data files.  
-----------------

It mentiones an "implementation-defined return value". 

So, I see no violation of the ANSI C standard when looking at the 
current system() implementations in several UNIX(like) OS. 

Wolfgang

Post a reply to this message

Thorsten Froehlich wrote:
> 
> #include <stdlib.h>
> #include <stdio.h>
> int main(int ac, char **av)
> {
>     printf("Result: %d\n", system(av[1]));
>     return 0;
> }
> 
> This should work and demonstrate that the system works correctly and only

    Don't work. In you invoke a.out with no args, av[1] is NULL.
    nonsense code sometime give intended results...

Post a reply to this message

Thierry Boudet wrote:
> Thorsten Froehlich wrote:
>> 
>> #include <stdlib.h>
>> #include <stdio.h>
>> int main(int ac, char **av)
>> {
>>     printf("Result: %d\n", system(av[1]));
>>     return 0;
>> }
>> 
>> This should work and demonstrate that the system works correctly and only
> 
>     Don't work. In you invoke a.out with no args, av[1] is NULL.
>     nonsense code sometime give intended results...
>
You probably misunderstood Thorsten here. 

I think he meant the above program to be used instead of "echo $?", 
i.e.:

shell> ./thorstens_program PX

where PX is a program with exit code >256. 

Wolfgang

Post a reply to this message

In article <40e71339@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

> Maybe you could even tell us where you found this information.

Section 5.1.2.2.3 of the ISO C 1999 standard - this is the section
specifying that main returns an "int" to the host environment.  It also
explicitly states that if and only if the result is _not_ an "int" the
behavior is implementation defined.  It does not make any provisions for
range reductions performed by the host environment.

Of course, this does not answer a more relevant _rhetoric_ question: Why is
there a need to butcher the program result on some systems in the first
place!  A simple C "int" certainly does not require extraordinary amounts of
memory...

    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

Ok, test done on my Ultra5/Solaris 8/Gcc 3.0.1 box :

- Many warning like in parse.cpp & parstxtr.cpp:

parse.cpp: In function `void pov::Parse_Camera(pov::CAMERA**)':
parse.cpp:1679: warning: assignment to `int' from `double'
parse.cpp:1679: warning: argument to `int' from `double'

[...]

parstxtr.cpp: In function `void pov::Make_Pattern_Image(pov::IMAGE*, 
FUNCTION*,
    int*)':
parstxtr.cpp:140: warning: assignment to `int' from `float'
parstxtr.cpp:140: warning: argument to `int' from `float'
parstxtr.cpp:141: warning: assignment to `int' from `float'
parstxtr.cpp:141: warning: argument to `int' from `float'
parstxtr.cpp:165: warning: assignment to `short unsigned int' from `double'
parstxtr.cpp:165: warning: argument to `short unsigned int' from `double'

- Trying to use X, the compilation fails as already said by some other 
people :

g++ -DHAVE_CONFIG_H -DPOVLIBDIR=\"/usr/local/share/povray-3.6\" 
-DPOVCONFDIR=\"/usr/local/etc/povray/3.6\" 
-DPOVCONFDIR_BACKWARD=\"/usr/local/etc\" -I. -I. -I..  -I.. -I../source 
-I../source/base -I../source/frontend -I../source -I../libraries/zlib 
-I../libraries/png -I../libraries/tiff/libtiff  -I/usr/openwin/include 
  -pipe -Wno-multichar -O3  -c -o xwin.o `test -f 'xwin.cpp' || echo 
'./'`xwin.cpp
In file included from xwin.cpp:122:
/usr/openwin/include/X11/Xlib.h:2099: ISO C++ forbids declaration of
    `XSetTransientForHint' with no type

- I can't disable X : --without-x shown

===============================================================================
POV-Ray 3.6 has been configured with the following features:
   I/O restrictions: enabled
   X Window display: enabled
   SVGAlib display : disabled


But another question : Why do we recompile every library even if they 
are already on the system (Libpng, libz, ...) ?

Bye

Lolo

PS: Test ongoing on my SparcServer5/NetBSD 1.6/Gcc 2.95.3 box but I 
think it should fails if I can't disable X (as X isn't installer on this 
"server").
PS2: Tomorrow, text on my HP-712 workstation under HP-UX 10.20 ...

Post a reply to this message