This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]