X-Recipient: archive-cygwin AT delorie DOT com X-Spam-Check-By: sourceware.org Date: Tue, 1 Sep 2009 19:37:50 -0400 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: struct dirent.d_reclen Message-ID: <20090901233750.GA32145@ednor.casa.cgf.cx> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , 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 05:39:02PM +0000, Eric Blake wrote: >Wish list (probably post 7.1): As long as we are making struct dirent more like >Linux with the recent addition of d_type, we should probably also burn two of >the remaining 3 __d_unused1 bytes to declare unsigned short d_reclen, whose >value is always strlen(d_name), so that applications could get by with fewer >strlen calls. Coreutils ls would certainly benefit from this optimization. Defining d_*rec*len as strlen(d_name) would not be correct since that is supposed to be the length of the record not the name. That's why linux has macros that look like this: # define _D_ALLOC_NAMLEN(d) (((char *) (d) + (d)->d_reclen) - &(d)->d_name[0]) Maybe you mean d_namlen? 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. 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