Re: mkoctfile exits with 0 if gcc failed

[Mike Miller]

On Wed, Jun 04, 2014 at 14:58:09 +0200, Andreas Weber wrote:
> Dear maintainers,
> 
> mkoctfile returns 0 if the called subprocess returns != 0.
> 
> One example:
> ~/src/octave-src$ LC_ALL=C mkoctfile nonexistentfile.cpp
> g++: error: nonexistentfile.cpp: No such file or directory
> g++: fatal error: no input files
> compilation terminated.
> g++: error: nonexistentfile.o: No such file or directory
> ~/src/octave-src$ echo $?
> 0
> 
> This is because system returns the exit status of the called process in
> the upper 8bits. According to "man wait" WIFEXITED and WEXITSTSTUS
> should be used for the bit shifting and masking stuff.

Good catch! This is probably a regression on Linux/Unix systems from
3.8.0 to 3.8.1 when we dropped the mkoctfile shell script. You might
want to report this on the bug tracker just so we have a better record
of it and a bug number in the hg log to refer back to later if needed.

> I propose the following patch:
> 
> diff -r 0ede4dbb37f1 src/mkoctfile.in.cc
> --- a/src/mkoctfile.in.cc       Sun Mar 30 14:18:43 2014 -0700
> +++ b/src/mkoctfile.in.cc       Wed Jun 04 14:42:58 2014 +0200
> @@ -344,7 +344,10 @@
>  {
>    if (debug)
>      std::cout << cmd << std::endl;
> -  return system (cmd.c_str ());
> +  int result = system (cmd.c_str ());
> +  if (WIFEXITED (result))
> +    result = WEXITSTATUS (result);
> +  return result;
>  }
> 
> 
> which works but I get the following warnings when compiling mkoctfile on
> debian wheezy 64bit with gcc 4.7.2:
> mkoctfile.cc: In function ‘int run_command(const string&)’:
> mkoctfile.cc:348:7: warning: use of old-style cast [-Wold-style-cast]
> mkoctfile.cc:349:14: warning: use of old-style cast [-Wold-style-cast]
> 
> 
> The old style cast is defined in /usr/include/stdlib.h:55
> #ifdef __USE_BSD
> .....
> #define __WAIT_INT(status)    (*(int *) &(status))
> 
> Any hints what should be done to avoid these warnings?

I see the same macros used in src/main.in.cc, do the same warnings show
up there? I think this is the only portable way to get the return
status so there's not much to do about it.

-- 
mike