RFC: fenv.h

David Schultz das at FreeBSD.ORG
Wed Jun 9 23:04:15 GMT 2004


On Wed, Jun 09, 2004, Stefan Farfeleder wrote:
> On Wed, Jun 02, 2004 at 12:32:35AM -0700, David Schultz wrote:
> > The following patch adds the fenv.h header to FreeBSD.  I would
> > appreciate any reviews of these changes.  Descriptions of the various
> > functions are included in the patch in the form of some manpages.
> 
> Thanks for committing this!
> 
> Just a small nit: Using inline functions with internal linkage to
> implement standard library functions isn't 100% conforming.
> 
> 7.1.2#6:
>   Any declaration of a library function shall have external linkage.
> 
> 7.1.4#2:
>   Provided that a library function can be declared without reference to
>   any type defined in a header, it is also permissible to declare the
>   function and use it without including its associated header.

Yeah, I know, but gcc makes the implementation of this detail very
ugly!  There are three kinds of inline functions: 'static inline',
'extern inline', and just plain 'inline'.  If we had a C99-conformant
compiler, we could just say this:

fenv.h:

	inline int fefoo(int x) {
		...
	}
	
fenv.c:

	extern inline int fefoo(int x);

This would automatically generate a symbol fefoo() in libm, and it
would tell the compiler to either inline calls to fefoo(), *or*
generate an external reference to the version in the library.

However, gcc disagrees with the C99 standard on the meaning of
'inline' and 'extern inline'.  The only case in which gcc and the
standard agree is 'static inline'.  As you pointed out, this
results in not-quite-standard definitions.  It also wastes a
little bit of space.

The rationale for doing things this way is that the gcc developers
are planning on implementing C99-style inlines.  At this point, we
don't know what the appropriate compile-time test will be to
determine whether we have the old gcc or the new gcc, because the
new gcc doesn't exist yet.  Therefore, any solution of the form
`#if __GNUC__ >= ...' is going to break some day.  I'm hoping that
with the way I did it, it will be easy to fix ``the right way''
when gcc's inline misfeature is gone.

BTW, our <ctype.h> has a nasty but simple kludge to work around
the problem.  If you can't wait for the gcc developers, you're
welcome to port that solution.


More information about the freebsd-standards mailing list