Re: Git 2.54.0-rc1, subtests of t5310, t5326, t5327

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

<rsbecker@nexbridge.com> writes:

> On April 8, 2026 4:22 PM, Junio C Hamano wrote:
>><rsbecker@nexbridge.com> writes:
>>
>>> On my box, I have the following note:
>>>
>>> Specifying  the sum of the iov_len values in the iov array greater
>>> than the OSS I/O size limit for that open causes the  writev()
>>> function  to return  -1  and  set errno to [EINVAL].
>>
>>That is unexpected.
>>
>>writev() may fail if the sum of iov_len would not fit within ssize_t with
> EINVAL, but
>>unless your "the OSS I/O size limit" is the same as SSIZE_MAX, what you
> have above
>>is not quite the same.
>>
>>Does your build work with NO_WRITEV=Nope?  I think I saw it asked a few
> times
>>but I do not recall seeing it answered.  At least we know
>>xwrite() seems to work well enough on your system, which is what the
>>writev() emulation is written in terms of, so I suspect it would.
>
> Yes, NO_WRITEV=Nope does compile and execute. I am including it
> in our CI/CD job for now. Can we plan on a fix for this?

What I have heard so far indicate that the code that uses writev()
would need to loop over to prepare for short writes, but your
writev() that fails for "the OSS I/O size limit" (whatever it is)
does not sound like something we want to change the callers to chomp
the writev() calls into smaller chunks for.  Such a platform is far
better off using the compat/writev for the code path we recently
started using writev() in.

To be quite honest, I am not sure if it is even worth using writev()
if we need a loop that protects against shrot writes, so unless I am
grossly mistaken (e.g., perhaps there is some guarantee that there
won't be any short writes for writev() that sends data smaller than
64k that I missed in the docs), the best course of action might be
to revert the change to use writev() and use the two write(2)s as
before, *if* we actually observe that the current code is broken by
short writes.