Re: 2.54.0-rc1 NO_WRITEV=Nope does not work

[Jeff King <peff@peff.net>]

On Thu, Apr 09, 2026 at 03:48:16PM -0400, rsbecker@nexbridge.com wrote:

> With a completely clean build, we are getting writev() being used anyway on
> NonStop:
> 
> /usr/coreutils/bin/make NO_TCLTK=NoThanks NO_WRITEV=Nope V=1
> prefix=/usr/local-ssl3.5 CFLAGS=-g -O2 -D_LARGEFILE64_SOURCE=1
> -D_FILE_OFFSET_BITS=64 -Winline -I/usr/local-ssl3.5/include
> -I/usr/coreutils/include -I/usr/tandem/xml/T0625L01_AAE/include
> LDFLAGS=-D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64
> /usr/coreutils/lib/libz.a -L/usr/local-ssl3.5/lib -L/usr/coreutils/lib
> -L/usr/tandem/xml/T0625L01_AAE/lib SHELL=/usr/coreutils/bin/bash
> GIT_VERSION=2.54.0.rc1

Hmm, the plot thickens. I think our fallback wrapper is being overly
picky. It does:

           for (int i = 0; i < iovcnt; i++) {
                  if (iov[i].iov_len > maximum_signed_value_of_type(ssize_t) ||
                      iov[i].iov_len + sum > maximum_signed_value_of_type(ssize_t)) {
                          errno = EINVAL;
                          return -1;
                  }
  
                  sum += iov[i].iov_len;
          }

so you are probably hitting that EINVAL! Which is trying to emulate how
a system writev() would work, but the fundamental problem is that it
_doesn't_ work on your system, because ssize_t is too small for how
we're using writev(), which assumes we can pass in 64k at a time.

It is tempting to just delete the EINVAL check shown above, but then the
rest of the fallback function needs to be more clever, and return a
partial write before incrementing total_written over the ssize_t limit
(otherwise we have no way to report to the caller how much was actually
written).

Yuck. I think for 2.54 we either have to truly implement MAX_IO_SIZE
support, or we have to revert the use of writev() in send_sideband()
until we do.

-Peff