[PATCH] glob: Simplify the interface for the GLOB_ALTDIRFUNC callback gl_readdir

[Florian Weimer]

On 04/11/2016 11:19 PM, Roland McGrath wrote:
>> I'm trying to get clarification if getdents on Linux can ever return
>> zero d_ino values.  It's going to be difficult to work this out due to
>> the VFS layer.  My hunch is that inode 0 is more likely to mean  I can't
>> tell you the inode number right now here , and not  please skip this entry .
>
> I don't know where your hunch comes from, but I don't believe it for a
> second.  The d_ino==0 convention has been universal in Unix since before
> Linux existed.  Any filesystem that returns d_ino==0 entries for getdents
> will have those entries completely ignored by userland, so I doubt anyone
> has implemented a filesystem that way.

Non-GNU userland would work, so it could be a file system restricted to 
embedded applications.

>> +An implementation of @code{gl_readdir} should initialize the
>> +@code{struct dirent} object to zero, up to the @code{d_name} member.
>> +The @code{d_ino} member must be set to a non-zero value, otherwise
>> +@code{glob} may ignore the returned directory entry.
>
> This wording is awkward.  It seems to contradict itself, as it first
> implies that d_ino should be zero and then says it must be nonzero.  I'm
> not convinced this "zero the object" advice is the way to go anyway.  If
> there is struct padding in struct dirent, it doesn't matter that it be
> zero.  If it has d_namlen, it (now) doesn't matter what it contains at all.
> Perhaps it's better to say just which fields glob examines and that the
> protocol requires only that those fields be set.
>
> Regardless of what we settle on as best practice, I think we want a little
> code example here that demonstrates it.

Right.  I realized that d_type and d_ino are unconditionally available 
in glibc, so I got rid of the memset and spelled out all relevant 
members explicitly.  I added the mkdirent example function in the new 
version of the patch.

> @code{glob} examines the @code{struct dirent} object only immediately after
> each call to your @code{gl_readdir} callback function and does not store
> the pointer returned.  That pointer is not expected to remain valid after a
> subsequent call to the @code{gl_readdir} or @code{gl_closedir} callback.  A
> common way to implement these callbacks it to reuse the same buffer each
> time the @code{gl_readdir} function is called and free the buffer in the
> @code{gl_closedir} function.

I expanded a bit on that in the new version of the patch, too.  I hope 
the table nesting isn't too awkward.  To me, it looks okay in Info, HTML 
and PDF.

Florian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-glob-Simplify-the-interface-for-the-GLOB_ALTDIRFUNC-.patch
Type: text/x-patch
Size: 7786 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20160412/947b4d21/attachment.bin>