%% "J. Grant" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 _______________________________________________ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make