On Tue, Jul 8, 2014 at 12:03 PM, Mark Kettenis <[email protected]> wrote:
> I disagree with this diff.  We should discourage the use of GNU
> extensions in our kernel.  Therefore I think std=gnu99 would give the
> wrong signal.

Can you clarify your concern?  Currently we're (implicitly) compiling
with -std=gnu89, which is ISO C90 + GNU extensions.  This diff changes
us to (explicitly) compile with -std=gnu99 -fgnu89-inline, which is
ISO C99 + GNU extensions + GNU C89 inline.

I think moving from C90 to C99 is a good idea.

I'm indifferent to GNU extensions.  If we could make do without them,
then great; but technically inline asm is a GNU extension (even if
it's available in C99 mode) and I doubt we'll benefit from eliminating
that.

Using GNU89 inline is an intermediary step, because the kernel isn't
ready for C99 inline.  See below.

> As for the inline issue.  IMHO, given the incompatbility problems
> between ISO C and GNU C, only "static inline" is usable.  The
> semantics of the other inline "forms" is just too confusing.  The
> occasional extra copy of the code is as far as I'm concerned
> acceptable.  The functions should be small enough for it not to
> matter.

Converting the existing inline functions to be C99 compatible (either
by adding static or removing inline) is a next step I have planned,
but I want to allow other C99 features first.

Also, there are "inline" functions in MD code, so I'd rather have all
kernels on -std=gnu99 -fgnu89-inline.  Then we can start cleaning up
GNU89 inlines and remove -fgnu89-inline on arches once they're clean.
E.g., first clean up all MI and x86 inlines, then the x86 kernels can
start compiling without -fgnu89-inline, which will make sure we don't
regress in MI code while we start tackling other MD files.

Reply via email to