Perry E. Metzger wrote:

>YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp> writes:
>  
>
>>>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.
>  
>
Actually, what you want is to check for either STDC not defined or
grearter than 1990.  You only need to guard these bare keywords with
underscores if strict ANSI is enabled and the keyword is not part of the
applicable ANSI C standard.

>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.
>  
>
Hopefully there aren't too many gnuisms in the headers for userland
code.  It should definitely be allowed to suppress them with ANSI (using
leading underscores is OK).  Basically, ANSI wants to verify that the
the namespace is clean -- so anything that isn't in the standard better
be defined with leading underscores (which is reserved for the system.)

>  
>
>>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.
>  
>
If it contains inline, it had better be conditionalized and fall back to
__inline or somesuch.

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


-- 
Garrett D'Amore                          http://www.tadpolecomputer.com/
Sr. Staff Engineer          Extending the Power of 64-bit UNIX Computing
Tadpole Computer, Inc.                             Phone: (951) 325-2134