> >> Perhaps the right thing is to conditionalize a rename of inline in our
> >> headers on __STRICT_ANSI__, which would be defined any time this was
> >> an issue.
> >
> > no.  the right way to check c99 is __STDC_VERSION__ >= 199901L.
> 
> Not quite. All compilers NetBSD has been released with handle "inline"
> naked, even if __STDC_VERSION__ is smaller than 199901L. "inline" was
> in gcc since 1990 at least.
> 
> The issue is unique for compilation under NetBSD with -ansi -- if
> __STRICT_ANSI__ is defined we have an issue.
> 
> We have a lot of gnuisms in our code base -- we wouldn't compile
> without gcc anyway -- so I think __STRICT_ANSI__ is the better test.

IMO, there is no point to introduce another gnuism here.

> > in any case, endian.h should use __inline.
> 
> endian.h isn't the only problem. There are other standard include
> files that contain "inline". See stdio.h for example.
> 
> Either we say "C99", or we put in a hack, or we back out to "__inline"
> for all include files that are mentioned in POSIX.
> 
> I think the most strictly correct thing is to use "__inline" for all
> include files mentioned in POSIX. However, maybe the #ifdef hack I
> mentioned to you in private mail would work. I'm not sure. I am
> somewhat inclined to back out to "__inline" for POSIX include files
> for now, but I want to think about it.

i think it's better to back to __inline for all public headers,
not limited to posix ones.

YAMAMOTO Takashi