On Sep13, 2011, at 16:25 , Tom Lane wrote:
> Florian Pflug <fgp@phlo.org> writes:
>> On Sep13, 2011, at 15:05 , Aidan Van Dyk wrote:
>>> Personally, I'ld think that's ripe for bugs. If the contract is that
>>> ret != amount is the "error" case, then don't return -1 for an error
>>> *sometimes*.
>
>> Hm, but isn't that how write() works also?
>
> Yeah. It's not possible to maintain the same error-reporting contract
> that bare write() has got, unless you're willing to forget about actual
> errors reported by a non-first write attempt.
Hm, yeah, but we're only replacing the exclusive or in "either sets errno
*or* returns >= 0 and < amount" by a non-exclusive one. Which, in practice,
doesn't make much difference for callers. They can (and should) continue to
check whether they correct amount of bytes has been written, and they may
still use errno to distinguish different kinds of errors. They should just
do so upon any error condition, not upon us returning -1.
The important thing, I believe, is that we don't withhold any information
from callers, which we don't. If write() sets errno, it must return -1,
so we'll abort and hence leave the errno in place to be inspected by the
caller. And we faithfully track the actual number of bytes written.
Or am I missing something?
> But if you do want to report such errors, I think you have to push the
> error reporting logic into the subroutine, which seems a bit messy since
> there's quite a variety of error message phrasings out there, all of
> which require information that write() itself does not have. Also, we
> do *not* want e.g. gettext() to be invoked unless an error actually
> occurs and has to be reported.
Yeah, I had the same idea (moving the error reporting into the subroutine)
when I first looked at the OP's patch, but then figured it'd just complicate
the API for no good reason.
best regards,
Florian Pflug