X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,TW_CG X-Spam-Check-By: sourceware.org X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.0 c=1 a=VphdPIyG4kEA:10 a=8nJEP1OIZ-IA:10 a=bjc4cVg0bOkbQAORHc9k3w==:17 a=w_pzkKWiAAAA:8 a=CXWoGiBcg3gvW84j8-IA:9 a=vNwHniieOFBWl1BaGugA:7 a=URYxkUWy1vlABOtK0Aj6mZKpOiIA:4 a=wPNLvfGTeEIA:10 a=9m-hJAl0gB8A:10 a=18NMdC4O5E9aOVqo:21 a=60C3rfsTe1p72elz:21 Message-ID: <4C5D7682.5030402@monai.ca> Date: Sat, 07 Aug 2010 08:06:42 -0700 From: Steven Monai User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: The dirent struct References: <20100806134005 DOT GD22459 AT ednor DOT casa DOT cgf DOT cx> <20100806141140 DOT GC31783 AT calimero DOT vinschen DOT de> <20100806163925 DOT GE31783 AT calimero DOT vinschen DOT de> <20100806173153 DOT GB23627 AT ednor DOT casa DOT cgf DOT cx> <20100806182832 DOT GH31783 AT calimero DOT vinschen DOT de> <4C5CA945 DOT 6070601 AT monai DOT ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: 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 2010/08/06 8:21 PM, Chris Sutcliffe wrote: > On 6 August 2010 20:31, Steven Monai wrote: >> On 2010/08/06 11:48 AM, Chris Sutcliffe wrote: >>> I've decided to take a different approach and decided to implement it >>> as follows: >>> >>> #ifdef __CYGWIN__ >>> itr->d_fileno = entry->d_ino; >>> itr->d_reclen = strlen(entry->d_name); >>> #else >>> itr->d_fileno = entry->d_fileno; >>> itr->d_reclen = entry->d_reclen; >>> #endif >>> >>> I assume this is appropriate? >> >> No, not according to this: >> >> http://cygwin.com/ml/cygwin/2009-09/msg00031.html >> >> Quoting cgf from there: >> >> "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." > > Interesting. From an rtorrent perspective it's working as expected, > but as I previously stated, although rtorrent grabs the value, it > doesn't actually seem to do anything with it. > > I'll leave it as is for now (I figure having something there is better > than nothing at all). IMHO, this is an unsafe approach. If, in a future version, upstream decides to start using itr->d_reclen for its intended purpose, then the plausible-but-incorrect value you've put there could become the source of Cygwin-specific bugs. In principle, if you can't/won't put the correct value there (which I see Corinna has helpfully posted), then you ought to put an obviously incorrect value there instead, such as 0 or -1. Perhaps the safest approach, though, would be to remove (or comment-out) the d_reclen field from the itr struct. Then, if upstream *does* use that field in the future, you should get build errors to alert you of that. -SM -- -- 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