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

> Clean install of msys-1.0.10, gcc-3.4.0 most recent versions of necessary
> packages.

	It seems I cannot reproduce your problem using:

msys-1.0.10.exe
binutils-2.15.90-20040222-1.tar.gz
gcc-core-3.4.0-20040501-1.tar.gz
gcc-g++-3.4.0-20040501-1.tar.gz
mingw-runtime-3.3.tar.gz
w32api-2.5.tar.gz

	In this case I can compile the whole POV-Ray (with an additional
-D__CYGWIN on the command-line; the latter is now set in configure).

> /mingw/bin/gcc -o mkg3states -I.././../zlib   -pipe -O3 -march=pentiumpro
> -mtune=pentiumpro -malign-double -minline-all-stringops     -I.
> -I../libtiff   ../libtiff/mkg3states.c
> C:/WINNT40/Profiles/SLSAND~1.RDG/LOCALS~1/Temp/cc0Eaaaa.o(.text+0x201):mkg3states.c:
> undefined reference to `getopt'

	Can you tell me if the libtiff configure reports something like:

Checking system libraries for functionality to emulate.
Done checking system libraries.

	or if there is a line in between mentionning about getopt ?
If this is the case I guess I have a fix for it, though I could not
really test it reliably.

	- NC

Post a reply to this message

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

	You can ignore them -- they won't harm.

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

	Yes, this will be fixed in the final source distro.

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

	If you look at the output of configure, you'll see that these
libraries are compiled only when needed.

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

	I'd be interested to hear of your results  :-)

	- NC

Post a reply to this message

Nicolas Calimet <pov### [at] freefr> wrote:
> > - Many warning like in parse.cpp & parstxtr.cpp:
>
>  You can ignore them -- they won't harm.

Ok, there is no way to remove them (like using casting) ?

[...]

> > 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 ...
>
>  I'd be interested to hear of your results  :-)

Under HP-UX 10.20 (I know, it's quite obsolete), the compilation fails due
to lack of vsnprintf() :-(

Bye

Laurent

Post a reply to this message