Re: [RFC] cocci: .buf in a strbuf object can never be NULL
- From
Jeff King <peff@peff.net>
- Date
- Mar 22, 2026, 01:44 UTC
- Message-ID
- <20260322014430.GB816875@coredump.intra.peff.net>
- In-Reply-To
- <ca9fa6c7-f693-4b85-a17f-8deeb05b45f7@web.de>
On Sun, Mar 22, 2026 at 12:41:04AM +0100, René Scharfe wrote:
Show 7 quoted lines
> > - make a noop read on an unallocated strbuf retain the unallocated > > state (your example above) > > That makes the function conform to the convention of rolling back on > error. This transactional behavior is a bit easier to understand. The > non-getdelim(3) version doesn't do that, though. It returns whatever > it got and leaves error checking and rollback to its callers.
Yeah, I didn't look at the fallback version. They definitely should match if we are going to change the behavior on an unallocated strbuf.
Show 6 quoted lines
> getdelim(3) doesn't allow that -- it has no way to indicate the length > of partial reads. If we are OK with throwing away partial lines then > we better do that consistently in both versions? Sounds a bit messed > up to bin perfectly good data just because some other platform has a > fancy function that goes quiet when it stumbles. The alternative of > having inconsistent behavior seems worse, though.
I'd expect a partial read via getdelim() to return the number of bytes read, and set an internal flag such that ferror(f) returns true (and return -1 next time). But that is based more on wishful thinking than looking at the implementation (and the details may even vary between implementations).
To some degree, one you see an error on a FILE handle, all bets are off, and keeping or throwing away a partial line or not is not really important. You can't realistically go back and retry.
-Peff