svn commit: r202661 - head/lib/libc/gen
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:
| The following shall be declared as a function and may also be defined
| as a macro:
|
| int uname(struct utsname *);
Modified:
head/lib/libc/gen/Symbol.map
head/lib/libc/gen/uname.c
Modified: head/lib/libc/gen/Symbol.map
==
--- head/lib/libc/gen/Symbol.mapTue Jan 19 23:03:08 2010
(r202660)
+++ head/lib/libc/gen/Symbol.mapTue Jan 19 23:07:12 2010
(r202661)
@@ -296,6 +296,7 @@ FBSD_1.0 {
tcflow;
ualarm;
ulimit;
+ uname;
unvis;
strunvis;
strunvisx;
Modified: head/lib/libc/gen/uname.c
==
--- head/lib/libc/gen/uname.c Tue Jan 19 23:03:08 2010(r202660)
+++ head/lib/libc/gen/uname.c Tue Jan 19 23:07:12 2010(r202661)
@@ -33,15 +33,15 @@ static char sccsid[] = From: @(#)uname.
#include sys/cdefs.h
__FBSDID($FreeBSD$);
+#define uname wrapped_uname
#include sys/param.h
#include sys/sysctl.h
#include sys/utsname.h
#include errno.h
+#undef uname
int
-__uname(struct utsname *name)
+uname(struct utsname *name)
{
return __xuname(32, name);
}
-
-__sym_compat(uname, __uname, FBSD_1.0);
___
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r202661 - head/lib/libc/gen
Thank you. mcl ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r202661 - head/lib/libc/gen
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 ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to svn-src-all-unsubscr...@freebsd.org
Re: svn commit: r202661 - head/lib/libc/gen
* Bruce Evans b...@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 e...@80386.nl WWW: http://80386.nl/ pgpgdbdOic0D3.pgp Description: PGP signature
