This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: The dirent struct
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