I guess these flags are documented only here

Why is the + 1 here? For AUTODRAIN routines it means that sbuf has to allocate 4097->8192 bytes.

I’m not sure it makes any sense for the non-autodrain interface either. I haven’t investigated the history, but IMO it can be dropped.

The only real benefit is zeroing new struct fields as they are added in the future. Your proposal plus bzero would be similar. In this context I agree it is not especially useful.

Fair point. I guess padding is unspecified in the C99 compound literal still.

I think the idea is that sbufs are always nul-terminated / always reserve a byte of the buffer for a trailing nul. So to the extent buflen is derived from uio_resid, rather than a truncated value, we want to fulfill the entire request. However, I think that just means we should move the + 1 above, something like:

buflen = io->uio_offset + uio->uio_resid + 1;
...
sb = sbuf_new(..., buflen, ...);
...
if (!(pn->pn_flags & PFS_AUTODRAIN)) {
    if (error == 0)
        buflen = sbuf_len(sb);
    else
        /* In overflow case, valid length does not include trailing nul. */
        buflen--;
    error = uiomove_frombuf(..., buflen, ...);
}

Hm, I'm reconsidering this.

(1) Chrome tries to read exactly a page at a time, and it's a bit silly to limit each chunk to 4095 bytes.

(2) sbuf itself shouldn't be 'extending' our given size, because we do not use the SBUF_AUTOEXTEND flag. So I think sbuf will just malloc(4097) bytes. Is the 4097 -> 8192 you're thinking coming from malloc(9)?

This needs to return len + the number of bytes we skipped in the partial seek case above. Fixed in my local tree.

Yes, my belief is that malloc() will end up using two whole pages for a 4097-byte allocation. Not the end of the world, but if we go that route I think it'd be worthwhile to add a comment.

Does SBUF_INCLUDENUL help you here?

Ah, ok.

SBUF_INCLUDENUL doesn't help; it only changes how sbuf_len() behaves.

We'd probably prefer a new SBUF_BINARY mode (or something) which does not reserve a byte for trailing NUL, but the 4095 thing isn't the end of the world (nor 2 pages).

Hmm, SBUF_INCLUDENUL also determines whether the nul byte is included in the buffer passed to the drain function, but that's not what we want here. So the choices are to add a new mode as you suggested, overallocate, or drain 4095 bytes at a time.

For now, I've gone with the 4095-at-a-time option.