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

Patrick Steinhardt [off-list ref] writes:

On Mon, Jul 27, 2026 at 08:44:39AM -0700, Junio C Hamano wrote:

quoted

Johannes Sixt [off-list ref] 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.