%% "J. Grant" <[EMAIL PROTECTED]> writes: >> All of these are not going to be easy to fix. The code is actually >> created that way for a reason, IIRC.
jg> It will be a little difficult to work out what the code is that is jg> compiled, as there seems to be (traditionally) excessive use of jg> pre-processor macro expansion to inline code. Could we update to jg> be inline functions which we can leave the compiler to decide if jg> it that suits the build config to inline? Well we can't use inline functions per se. GNU make still attempts to be compilable by old K&R C compilers: it doesn't even rely on features available in the first (1989) ANSI C standard, much less features not found until the second (1999) ISO C standard (which is where inline was introduced). In the next release I'll probably give up portability to K&R compilers, but I'll still require portability to the 1989 C standard. If you meant, replace the macros with static functions in the header file I suppose that would be possible, but I'm not sure it's really going to be that much clearer what's going on. Anyway, Paul Eggert provided those macros. I deciphered them once upon a time and what I remember from that was that the code the warnings warned about were essential to the way the macros worked. jg> I did cvs update -d after your last commit, and also just now. My jg> code still gives me that warning. I am using gcc (GCC) 3.3.5 jg> (Debian 1:3.3.5-8) on on an i586. Huh. Oh, I see; it only shows up with optimization on. These are there because we're using vfork() in these functions. vfork() has the interesting property that the child process has write access to the memory of the parent process--not just copy-on-write, but access to the actual same memory. So, when you're in the child of a vfork() you have to be extra careful: basically the only legal thing to do there is exec(). vfork() was invented specifically as an efficiency improvement for the 99% of the time when you use fork() just to turn around and exec(). 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. -- ------------------------------------------------------------------------------- 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
