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

[Bruce Evans]

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