Re: [PATCH/RFC] inline cleanup/C89 support

[Rich Felker <dalias@aerifal.cx>]

On Tue, Sep 04, 2012 at 05:49:12PM +0200, philomath wrote:
> On Sun, 2 Sep 2012 12:51:26 -0400
> Rich Felker <dalias@aerifal.cx> wrote:
> 
> > On Thu, Aug 30, 2012 at 03:45:34PM -0700, Isaac Dunham wrote:
> > > On Fri, 24 Aug 2012 09:53:16 +0200
> > > Szabolcs Nagy <nsz@port70.net> wrote:
> > > 
> > > > * Rich Felker <dalias@aerifal.cx> [2012-08-23 22:34:25 -0400]:
> > > ...
> > > > > #if __STDC_VERSION__ >= 199901L
> > > > > #define __inline inline
> > > > > #define __restrict restrict
> > > > > #endif
> > > > > 
> > > > > added near the top of headers that need to use inline and/or
> > > > > restrict.
> > > (As previously stated, it appears-per a grep of glibc-that restrict is
> > > not needed in these headers.) 
> > > This patch is updated for C++:
> > > 
> > > #if __STDC_VERSION__ >= 199901L || defined(__cplusplus)
> > > #define __inline inline
> > > #endif
> > > [...]
> > 
> > Committed, with minor changes.
> > 
> > Rich
> 
> 
> Sorry for asking after the fact, but why the whole code-duplication? why not
> have an internal header (like glibc's cdefs.h) for these kind of things (inline,
> restrict, noreturn, etc) and include it where needed?

It's really a matter of weighing the costs against the benefits. The
duplication is minimal and it's not code that should require
maintenance; even if it did, maintenance would be simple pattern
replacement. On the other hand, the cost is pretty high. For compiling
small C files, the whole compile job is dominated O(# calls to open)
and adding an extra junk header just to do this trivial definition of
__inline would increase compile times measurably.

Rich