bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Latest CVS make compile warnings fix


From: Paul D. Smith
Subject: Re: Latest CVS make compile warnings fix
Date: Sun, 10 Jul 2005 00:49:24 -0400

%% "J. Grant" <address@hidden> 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 <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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]