From owner-svn-src-all@FreeBSD.ORG Wed Jan 20 05:45:56 2010 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32472106566B; Wed, 20 Jan 2010 05:45:56 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by mx1.freebsd.org (Postfix) with ESMTP id A20718FC14; Wed, 20 Jan 2010 05:45:55 +0000 (UTC) Received: from c220-239-227-214.carlnfd1.nsw.optusnet.com.au (c220-239-227-214.carlnfd1.nsw.optusnet.com.au [220.239.227.214]) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o0K5jpMu000503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jan 2010 16:45:52 +1100 Date: Wed, 20 Jan 2010 16:45:51 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Ed Schouten In-Reply-To: <201001192307.o0JN7CKu034318@svn.freebsd.org> Message-ID: <20100120163243.A68431@delplex.bde.org> References: <201001192307.o0JN7CKu034318@svn.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r202661 - head/lib/libc/gen X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jan 2010 05:45:56 -0000 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