This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Linux: Add <sys/direntries.h>
* Adhemerval Zanella:
> On 08/07/2019 12:44, Florian Weimer wrote:
>> * Adhemerval Zanella:
>>
>>> Probably not many, even now you see on debian sparc maillist programs
>>> that raise alignment issue due sparc restrictions. But masking wrong C
>>> usage is not intention of such interfaces.
>>
>> I think code that's difficult to implement in a portable fashion may
>> have a place in glibc, particularly if it is closely related to a glibc
>> or kernel interface.
>
> But we do have dirent functions exactly to abstract it. If user wants to
> optimize by using more direct function, such as getdents, its usage are
> very specific and the auxiliary functions, as the one you intend to provide,
> are just guesses of what user might want.
I think the interfaces cover this use case pretty well:
<https://sourceware.org/ml/libc-help/2019-07/msg00007.html>
>>>> To support 64-bit directory offsets on 32-bit architectures, readdir and
>>>> readdir64 must call malloc after all previous telldir call, to allocate
>>>> space for the 64-to-32 mapping. telldir cannot report failure and
>>>> therefore cannot call malloc. So extending opendir in this way looks
>>>> rather problematic.
>>>
>>> I think you meant seekdir instead of telldir.
>>
>> No, I meant telldir. telldir needs space to store a new mapping if it
>> is called (which we do not know beforehand). We can preallocate a fixed
>> number of entries (one is quite enough), but if telldir has been called,
>> and *then* readdir is called, we need to make sure that we have space
>> for another mapping if telldir is called again.
>>
>> This is the proper fix for bug 23960 and is what FreeBSD does.
>
> Right, I see what you mean now. It was not clear you was referring to a
> possible solution of the telldir/seekdir issues where there is an extra map
> between the fs d_off and the expected result long type for telldir.
>
> But even the FreeBSD solution is to assume the return value will hold
> on 'long' return and allocate the new maps entries on a linked list
> external to the buffer used for getdirentries.
Yes, I think there is no way aound memory allocation for this. We can
make it rare enough if we pre-allocate just one place, though. I think
it's still a reasonable solution for a bad fringe case.
But it inteferes with using readdir in an async-signal-safe (or at least
malloc-unsafe) context, which is something people actually do. If we
intend to tell people to move to safer interfaces (useful after vfork or
just even multi-threaded fork), I think we are under an obligation to
provide such interfaces.
Thanks,
Florian