X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Wed, 2 Sep 2009 10:33:06 -0400
From: Christopher Faylor <cgf-use-the-mailinglist-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: struct dirent.d_reclen
Message-ID: <20090902143306.GA2726@ednor.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <loom DOT 20090901T193145-508 AT post DOT gmane DOT org>  <20090901233750 DOT GA32145 AT ednor DOT casa DOT cgf DOT cx>  <4A9DC5FC DOT 2070202 AT byu DOT net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4A9DC5FC.2070202@byu.net>
User-Agent: Mutt/1.5.20 (2009-06-14)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On Tue, Sep 01, 2009 at 07:10:20PM -0600, Eric Blake wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>According to Christopher Faylor on 9/1/2009 5:37 PM:
>> Maybe you mean d_namlen?
>
>Yes; serves me right for confusing readdir(2) and readdir(3) man pages.
>
>>It is not a given that adding d_reclen would speed anything up since it
>>cause every single program that uses dirent to effectively perform a
>>strlen on every record returned by readdir whether it needed that field
>>or not.  Making sure that field was filled out would also complicate
>>Cygwin's internal logic.
>
>Not so.  For example, fhandler_disk_file::readdir_helper is already doing
>a sys_wcstombs to populate the d_name buffer, and that returns the length
>as a side effect.  In other words, the cost of providing the length to the
>client is an O(1) single assignment of an already-existing value per entry
>(and when you consider that we are already assigning __d_unused1 to 0,
>that means no net increase in cost to clients that don't care about the
>length); whereas the current situation requires clients that care about
>the length to use O(n) strlen() and duplicate something that was
>previously calculated by cygwin1.dll.

Ok, I shouldn't have said "every record".  For disk files, The length is
even available in fname->Length.  However, there are other places where
the length is not available and would have to be calculated.  I know it's
a negligible cost but I'm not convinced that it is one worth taking.

(And, FWIW, setting a variable to zero is a very cheap operation)

Anyway, if we were going to do something like this, we'd make Cygwin
more like linux.  It sets d_reclen to the size of the structure.  There's
some more calculation for every readdir.

cgf

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple