> > 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.
With that explanation, this sounds a lot more reasonable.
