Re: proposed libc interface and man page for statmount(2)

[Florian Weimer <fweimer@redhat.com>]

* Miklos Szeredi:

> On Thu, 16 Nov 2023 at 21:36, Florian Weimer <fweimer@redhat.com> wrote:
>
>> In addition to Adhemerval's observation that we'd prefer to have some
>> hint regarding the buffer size, it's probably better to have entirely
>> separate interfaces because it makes static analysis easier.  With a
>> unified interface, we can still convey the information with an inline
>> wrapper function, but we can avoid that complexity.
>
> I'm not against having separate allocating and the non-allocating
> interfaces.

Thanks.

> But I don't think the allocating one needs a size hint.   Your
> suggestion of passing a buffer on the stack to the syscall and then
> copying to an exact sized malloc should take care of it.   If the
> stack buffer is sized generously, then the loop will never need to
> repeat for any real life case.

The strings could get fairly large if they ever contain key material,
especially for post-quantum cryptography.

We have plenty of experience with these double-buffer-and-retry
interfaces and glibc, and the failure mode once there is much more data
than initially expected can be quite bad.  For new interfaces, I want a
way to avoid that.  At least as long applications use statmount_allloc,
we have a way to switch to a different interface if that becomes
necessary just with a glibc-internal change.

Thanks,
Florian