From owner-freebsd-current@FreeBSD.ORG Wed Apr 16 05:52:06 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C2C31065676 for ; Wed, 16 Apr 2008 05:52:06 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id DA8B68FC16 for ; Wed, 16 Apr 2008 05:52:05 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [202.108.54.204]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 5A9AF28449 for ; Wed, 16 Apr 2008 13:52:04 +0800 (CST) Received: from localhost (tarsier.geekcn.org [202.108.54.204]) by tarsier.geekcn.org (Postfix) with ESMTP id 22AB1EC522F; Wed, 16 Apr 2008 13:52:03 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([202.108.54.204]) by localhost (mail.geekcn.org [202.108.54.204]) (amavisd-new, port 10024) with ESMTP id dKR8Q8OBzTbG; Wed, 16 Apr 2008 13:51:42 +0800 (CST) Received: from charlie.delphij.net (c-69-181-135-56.hsd1.ca.comcast.net [69.181.135.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 1A4EBEC5209; Wed, 16 Apr 2008 13:51:39 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=CpzK+JVp8Ewru/gRqWzbAdu7NRj/JG0m3trqcLqSG4WBtP5+49oDjhAWdnW8X1xaO w0rg2yFzLpUx5ot3hvmFg== Message-ID: <480593E7.1040106@delphij.net> Date: Tue, 15 Apr 2008 22:51:35 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.12 (X11/20080312) MIME-Version: 1.0 To: Kostik Belousov References: <48027F56.9010302@delphij.net> <20080414095539.GD18958@deviant.kiev.zoral.com.ua> <4803B0EC.1060901@delphij.net> <20080415090138.GK18958@deviant.kiev.zoral.com.ua> In-Reply-To: <20080415090138.GK18958@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 0.95.6 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , d@delphij.net Subject: Re: [PATCH] fdopendir(3) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Apr 2008 05:52:06 -0000 Kostik Belousov wrote: [...] >> Some observations. __fdopendir2(). My feeling is that this is not >> suitable to separate as a standard alone file as its sole users are >> fdopendir() and opendir(), therefore, being static might be more >> appropriate. Do you have the intention to use it in somewhere else? If > Being static, it must be present in the same source file with the > callers. Since the static libraries (libXXX.a) try to avoid bringing > in non-used symbols by separating each symbol in the individual source > file, I put the __fdopendir2, opendir and fdopendir into the individual > files. Yes, use of the opendir or fdopendir would bring the __fdopendir2 > in, but use of the opendir would not expose fdopendir extra. I agree most parts of your point, but I would say that by separating the function out to its own file, its symbol would be exposed if we provide libc.a (but it's right that .so would not be affected). For the sake of reducing statically linked program's size, will it be more helpful to split fts.c into several .c's in order to reduce the potentially imported symbols if we statically link the binary, as fdopendir() is only an interface translator which is simply a return statement, I would say that the affect would be small as compared to other parts of libc. Therefore I still feel that this is more or less an overkill to separate into individual files, especially when we do not intend to use __fdopendir2 in other parts of libc... >> so we should really repocopy opendir.c to __fdopendir2.c (there is a >> minor unnecessary. > I do intent to repocopy it. This cannot be represented in the patch. > >> Another thing is that the fd == -1 && (flags & DTF_REWIND) statement. >> If this would be an internal routine then it sounds like to be better >> represented as an assertion. The caller should guarantee that the >> assertion hold true (by design), and the runtime check seems to be >> unnecessary (that's why I did not added these checks). > Agree. > >> So I think the major difference between your version and mine is whether >> we wanted to expose __fdopendir2() outside libc? > Mine __fdopendir2() is also not exposed for the libc users, since it is > not present in the public symbol map. > nm DEV/src/lib/libc/libc.so.7 | grep __fdopendir2 > 000c1160 t __fdopendir2 > As you see, the symbol is local. -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve!