Re: Latest CVS make compile warnings fix

[Paul D. Smith]

%% "J. Grant" <address@hidden> writes:

  jg> Ulrich Drepper's recent "Dictatorship of the Minorities" springs
  jg> to mind:

  jg> http://www.livejournal.com/users/udrepper/7326.html

Heh.  Since one of Ulrich's main points is we shouldn't bother
supporting Windows I'm not sure you want to bring this up :-).

Nevertheless, I understand your point and for many programs I would
agree with it: but in the case of GNU make I hold it to a somewhat
higher standard because I regard it as a bootstrap tool.  A bootstrap
tool needs to work on a far wider array of older systems than "normal"
tools, because the bootstrap tool is required in order to bootstrap the
system into a better, more modern toolchain.

Of course you can say that one could just use an older version of GNU
make, and you'd be right, and that's the argument I'll use if someone
complains in the future.

  jg> Maybe this has already been discussed? (Idea of dropping
  jg> minority/legacy architectures which do not have a C90 compiler
  jg> toolchain).

I don't know about "discussion", but I've already stated a few times
that this (3.81) will be the last release of GNU make that I'll try to
support K&R compilers.  I will even start to get rid of various gross
code bits that say things like "necessary for broken SGI compiler", when
that comment was added back in 1993 or whatever.  I am also going to
make an effort to find out if anyone is still using GNU make on Amiga;
no one has sent me an Amiga patch since 3.75 or so: I actually wonder if
it even works on those systems anymore.  If no one can be found who uses
them and will maintain the port, I'll take all the Amiga support out.

In short, I anticipate that there will be a lot of code cleanup in 3.82
(or whatever the next major release is).  But now is not the time for that.

However, I won't lose compatibility with C90 for a while, so features
available only in C99 are still a ways off.

  jg> ansi2knr.c is in the soure tree, not sure what for though as it is
  jg> not built.

It would be built and used if autoconf detects that your compiler cannot
use ANSI C prototypes.

I have an old SunOS 4.1.4 system where the default compiler (cc) is K&R,
that I use to test this.

  jg> I expect those macros were intended to be used with signed values,
  jg> and now they are being used with unsigned values as well, which is
  jg> bad.

No, I don't think so.  I don't remember the details but my recollection
is that they were specifically designed to work with systems which used
either signed or unsigned values, without having to test for
that... because there's no way to test for that (remember that if you
want to be able to cross-compile, and I most definitely DO want make to
be cross-compilable, you cannot actually _RUN_ any programs during
autoconf time.  You can only compile/link programs).

  >> However when you use vfork() you have to be careful about modifying any
  >> values in the child process.
  >> 
  >> It's not clear to me why GCC is warning about these particular
  >> variables and not others.  And, I don't know that there's much that
  >> can be done about it.

  jg> Is there a reason fork() cannot be used?

Efficiency on older systems.  It could make a big difference, and make's
whole job in life is basically to fork/exec other stuff.

This is another prime candidate for removal in the next release, since
many systems don't even support vfork() anymore (on Linux I think it's
just a #define to fork, more or less).

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.paulandlesley.org
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist