Re: Latest CVS make compile warnings fix

[J. Grant]

[...]
> 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.

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

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

There was a discussion on binutils/gcc mailing list about K&C or C90
(ANSI/ISO 1989) last year if I remember correctly.  As gcc 2.95.2 could
be built on those propreitary architectures which still did not have a
C90 compliant compiler toolchain, the code was updated to be C90 in most
cases. (gcc 2.95.2 could be built and used to build the latest
gcc/binutils in those cases. I think HP-UX was the case where there was
not a C90 compatible compiler).  Similarly this could be the approach
taken with GNU make if a legacy architecture needed to use the 2005
release of GNU Make.

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

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

> 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.

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

Most compilers will inline small functions without even needing the
"inline" hint.

>   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.

Is there a reason fork() cannot be used?

Kind regards
JG
--
Homepage: http://jguk.org/
Blog: http://jguk.org/blog.rss
Radio: http://jguk.org/#radio