svn commit: r202661 - head/lib/libc/gen

Ed Schouten ed at 80386.nl
Wed Jan 20 07:04:11 UTC 2010


* Bruce Evans <brde at optusnet.com.au> wrote:
> Of course it is against standards.  This is implicit for most functions,
> and the part of the standard that you quoted says it explicitly for
> uname():
> 
> > | The following shall be declared as a function and may also be defined
>                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^     ^^^^^^^^
> > | as a macro:
> > |
> > | int uname(struct utsname *);
> 
> Examples of use of the function when it is also defined as a macro:
> 
> <snip>

It turned out I slightly misinterpreted the sentence. It should declared
as a function *and* may also be defined as a macro. When I read this at
first, I interpreted the word "and" as an "or", which in my mind makes
sense when you try to keep things simple. But yes, if uname wouldn't be
provided as a real function, there are many constructs that could of
course break.

The most confusing part about this, is that the uname function we
provide in libc doesn't match the one in <sys/utsname.h>, which uses 128
bytes instead of 32. Fortunately it's not possible to #undef the inline
function, but it still sounds quite scary to me.

-- 
 Ed Schouten <ed at 80386.nl>
 WWW: http://80386.nl/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-all/attachments/20100120/af45f52f/attachment.pgp


More information about the svn-src-all mailing list