Re: [PATCH 0/5] Reintroduce writev(3p)

[Junio C Hamano <gitster@pobox.com>]

Patrick Steinhardt <ps@pks.im> writes:

> On Mon, Jul 27, 2026 at 08:44:39AM -0700, Junio C Hamano wrote:
>> Johannes Sixt <j6t@kdbg.org> writes:
>> 
>> I think Patrick's writev(2) follows the pattern our previous compat/
>> routines have taken.  We use real writev(2) where it is available,
>> and in the fake implementations in compat/ we have comments that
>> essentially say "the real function offers X, Y, and Z, but we only
>> want X and Z and do not need Y, so this implementation does not
>> support Y".  It is harder to maintain because the application side
>> may be tempted over time to start depending on Y.  If some platforms
>> cannot easily provide an equivalent of the real function, it is
>> easier for them if the rules explicitly state from the beginning
>> that we do not require and will never require Y, needing only X and
>> Z from either the fake or real implementation.
>> 
>> At that point, we are not describing the real function anymore, so
>> your proposal to give it a specific name is one step away from that,
>> and that step is in the right direction.
>
> Yeah, I was mostly trying to follow the precedent that we currently have
> in our code base, where we assume POSIX functions and paper over any
> gaps that a specific platform has via compatibility wrappers. And I
> think that the compatibility wrapper we have for writev(3p) is close
> enough to the original semantics of it to not really matter much in
> practice.
>
> I overall don't disagree that it would've been nice at times to have a
> higher-level interface that abstracts over such platform specifics
> without assuming POSIX semantics. But I'm not really sure what it buys
> us to rename this to `write_gather()` without rethinking the bigger
> approach we have to I/O. That is, what does it buy us to now diverge
> from the current practice, and where do we want to end up?

As I am not the party who needs to implement a good enough
emulation, and what is hard to do in non POSIX environment that is
needed for writev(2) emulation, I think that is a question for j6t.

A different way to put the same question is "what is Y in the
context of the intended uses of writev(2) in our codebase"?

Thanks.