[PATCH] Improve NNTPconnect error reporting

Russ Allbery rra at stanford.edu
Mon Jun 7 01:38:53 UTC 2010

Ian Jackson <ijackson at chiark.greenend.org.uk> writes:
> Russ Allbery writes ("Re: [PATCH] Improve NNTPconnect error reporting"):

>> It might be.  That was always a really ugly wart in the network API and
>> I was cringing a bit when I wrote that last sentence in the
>> introductory comment.  It's frustrating that there are two entirely
>> separate error reporting mechanisms between the system calls and the
>> DNS lookups that complicate passing errors back.

> Also, with any connection routine like this that tries multiple
> addresses and address families, there's a question about which errno
> value to report, which leads to slightly obscure logic about saving and
> restoring errnos.

Yeah, also true.  I'm sure the current code doesn't do that properly.

> Another possibility would be to allow the caller to specify a callback
> function which gets told either a string, or some more information
> including h_errno or errno or what have you, and might be called more
> than once.

That would at least be the most complete solution, although it might be

>> I think adding a buffer to hold the error is kind of ugly, but if it's
>> the only way to get the real error out, it might be worth it.  I
>> suppose we could do something sneaky like return both positive and
>> negative error codes and distinguish between errno and h_errno that
>> way, but that's almost as ugly.

> I think the string buffer is probably least ugly but tell me what you
> think is best and I'll code it up.

A string buffer seems to be about the right level of complexity, at
least.  The only thing that makes me leery of it is that there's no good
way to size that buffer; one just has to take a guess at what would be big

On UNIX, you can probably get away with passing in a char ** and
allocating the error buffer on the fly, but I'd rather not go that route
just in case the INN version of this code is ever reunified with the
version that I use on other projects, since that breaks on Windows without
adding a corresponding function to free the error buffer.

Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

More information about the inn-workers mailing list