On Tue, Apr 11, 2017 at 6:51 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Magnus Hagander <mag...@hagander.net> writes: > > Something like the attached? > > Not sure about > > + * All methods that have a failure path will set errno on failure. > > Given that you've got a getlasterror method, I don't think that's really > the API invariant is it? If it were, you'd just have the callers doing > strerror(errno) for themselves. I think maybe a more accurate statement > would be > Hmm. You're right, this is what I get for rushing a patch before plane departure :/ > * All methods that have a failure return indicator will set state > * allowing the getlasterror() method to return a suitable message. > * Commonly, errno is this state (or part of it); so callers must take > * care not to clobber errno between a failed method call and use of > * getlasterror() to retrieve the message. > Yeah, that's much better. > Also: > > * the arguments of open_for_write() could stand to be explained > > * what's the return value of finish()? > Both fixed. > > * wouldn't it be better to declare getlasterror() as returning > "const char *"? > Yeah, probably is. Will do and push. Thanks! -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
