svn commit: r202661 - head/lib/libc/gen
Bruce Evans
brde at optusnet.com.au
Wed Jan 20 05:45:56 UTC 2010
On Tue, 19 Jan 2010, Ed Schouten wrote:
> Author: ed
> Date: Tue Jan 19 23:07:12 2010
> New Revision: 202661
> URL: http://svn.freebsd.org/changeset/base/202661
>
> Log:
> Revert r202447 by re-exposing the old uname(3) function.
>
> It makes hardly any sense to expose a symbol which should only be
> provided for binary compatibility, but it seems we don't have a lot of
> choice here. There are many autoconf scripts out there that try to
> create a binary that links against the old symbol to see whether
> uname(3) is present. These scripts fail to detect uname(3) now.
>
> It should be noted that the behaviour we implement is not against the
> standards:
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:
/* Avoid any macro definition of the function when calling it. */
(uname)(namep);
/* Take the address of uname in an obfuscated way. */
foo(uname);
/* Take the address of uname in an unobfuscated way. */
foo(&uname);
/* Try to debug uname. */
(gdb) b uname
Function "uname" not defined...
(gdb) #^#^^^@* someone defined uname as a macro :-(.
#undef uname
/* Now uname is not defined as a macro, though it may have been. */
uname(namep);
Bruce
More information about the svn-src-head
mailing list