On Jun 24, 2009, at 4:07 PM, Manuel Bouyer wrote:
On Wed, Jun 24, 2009 at 11:14:43PM +0200, Marc Balmer wrote:Am 24.06.2009 um 21:42 schrieb Manuel Bouyer:On Wed, Jun 24, 2009 at 09:00:53PM +0200, Marc Balmer wrote:I'd have phrased it differently, but I agree with Thor -- this is abad API. Nor have I seen sufficient evidence that it's widely used in software we might want to import.I am eager to learn why it is bad.I think Thor explained it quite well. And yes, I did look at the man page.he did not. he completely failed to back his strong words...I don't think so, I agree with his arguments.There isn't even proper matching between the possible errno and the possible errstr values in the man page ... We could change it so that errstr points to strerror(errno) but then there isn't much point in returning errstr at all.I think all the criticism circulates around this error string... but then thisis what the implementors did. it is not wrong. If you don't want thestring, pass NULLAnd they you don't know if something bad occured or not.
This is the part I don't understand. The common idiom for functions which return a status which is then reflected in errno is to return:
0 - success -1 - failureThen it's documented that "specific values for failure are in errno". This has been a common API design for a *long* time and works well, Where-as I cannot think of another design which returns hard coded string values as some error indication (except for strerror which is there for that entire purpose).
Look at it this way...If the error is in errno, what value does the string have? Zero basically since any modern program can't use it. You can't just print it back to a user (it's non localizable) and since errno gives you the same information there's no reason to use it to figure out the error condition either. So it's superfluous at best and likely confusing for the common case.
Good API's are simple, not the kitchen sink variety where there are N knobs to enable/disable different error reporting mechanisms.
James