On 7 December 2017 at 12:12, Jiri Svoboda <[email protected]> wrote: >> I mean, the proposal is about an extensible error system for all libraries > that want/need their own error codes, and at the same time interoperate > with code returning errors of their own. It's not about libhttp in > particular, > it's just that libhttp exhibits this pattern, much like many other places > in HelenOS. > What libhttp is doing with error codes is wrong. It should be fixed instead > of trying to bend errno_t to deal with it. The fact that other libraries are > possibly doing the same thing doesn't make it less wrong.
I lost you. This has little to do with errno_t. Are you saying every library should limit itself to <errno.h> constants? > -Jiri > > > ---------- Původní e-mail ---------- > Od: Jiří Zárevúcky <[email protected]> > Komu: HelenOS development mailing list <[email protected]> > Datum: 6. 12. 2017 22:16:27 > Předmět: Re: [HelenOS-devel] [RFC] Locally extensible error returns > > On 6 December 2017 at 22:04, Jiří Zárevúcky <[email protected]> > wrote: >> On 6 December 2017 at 21:20, Jiri Svoboda <[email protected]> wrote: >>> Hi Jiri, >>> >>> well this is maybe the least important problem that libhttp has. Why >>> don't >>> you just fix libhttp so that each of its functions either returns errno_t >>> or >>> an http_error_t that is completely separate type from errno_t? >>> >> >> Because that would be more difficult, as well as less beneficial in >> the long run. >> But of course, it's a possibility. >> > > I mean, the proposal is about an extensible error system for all libraries > that want/need their own error codes, and at the same time interoperate > with code returning errors of their own. It's not about libhttp in > particular, > it's just that libhttp exhibits this pattern, much like many other places > in HelenOS. It's not a solution for libhttp, it's a solution for the bugs > that > inevitably crop up when code mixes calls to functions with differing error > reporting behavior. Fixing those bugs is basically all I've been doing for > the past two days. > >> -- jzr >> >>> Regards, >>> Jiri >>> ---------- Původní e-mail ---------- >>> Od: Jiří Zárevúcky <[email protected]> >>> Komu: HelenOS development mailing list <[email protected]> >>> Datum: 6. 12. 2017 16:19:24 >>> Předmět: [HelenOS-devel] [RFC] Locally extensible error returns >>> >>> Hello, >>> For context: I've been working on fixing our errno.h use for the past >>> two days. It's going very well, I'll probably be done by tomorrow, and >>> I'll write a blog post about the entire process after I'm finished. >>> >>> The issue I'm facing now is simple: libhttp uses errno.h error codes, >>> but also defines its own bunch of error conditions, mixing them with >>> returns from libc functions. Obviously, this is not ideal. Such errors >>> can start conflicting with others on a later date, without any >>> indication that something is wrong, and it's not possible to just use >>> strerror() on such a return value, or return it from an interface that >>> expects libc error codes (for example, imagine a HTTP data transport >>> abstracted as a pipe -- such code would need to translate >>> HTTP-specific error codes, but there is no indication on type level >>> that that's necessary). >>> >>> That much for context. I thought about possible solutions, and this is >>> the best I came up so far. Instead of explaining in words, simplified >>> example of code: >>> >>> ---- >>> >>> // libc header >>> typedef struct { >>> const char *name; >>> const char *description; >>> } error_t; >>> >>> extern const error_t *E_NOMEM; >>> extern const error_t *E_IO; >>> ---- >>> // libhttp header >>> extern const error_t *HTTP_E_HEADERS; >>> >>> ---- >>> // libc object file >>> >>> static error_t _NOMEM = { "E_NOMEM", "Out of memory" }; >>> const error_t *E_NOMEM = &_NOMEM; >>> >>> static error_t _IO = { "E_IO", "IO failed" }; >>> const error_t *E_IO = &_IO; >>> >>> ---- >>> // libhttp object file >>> >>> static error_t _HEADERS = {"HTTP_E_HEADERS", "HTTP: Failed processing >>> headers" }; >>> const error_t *HTTP_E_HEADERS = &_HEADERS; >>> >>> ---- >>> // user >>> >>> const error_t *err = http_func_1(...); >>> if (err == HTTP_E_HEADERS) { >>> // process error >>> } else if (err == E_IO) { >>> // process other error >>> } else { >>> // process all other errors >>> fprintf(stderr, "Failed http operation: [%s] %s\n", err->name, >>> err->description); >>> exit(1); >>> } >>> >>> >>> >>> >>> >>> >>> >>> What do you think? >>> >>> -- jzr >>> >>> _______________________________________________ >>> HelenOS-devel mailing list >>> [email protected] >>> http://lists.modry.cz/listinfo/helenos-devel >>> >>> >>> _______________________________________________ >>> HelenOS-devel mailing list >>> [email protected] >>> http://lists.modry.cz/listinfo/helenos-devel >>> > > _______________________________________________ > HelenOS-devel mailing list > [email protected] > http://lists.modry.cz/listinfo/helenos-devel > > > _______________________________________________ > HelenOS-devel mailing list > [email protected] > http://lists.modry.cz/listinfo/helenos-devel > _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
