Date: Mon, 3 Mar 2014 00:31:22 +0400 From: Dmitry Selyutin <ghostman.sd@gmail.com> To: Julio Merino <jmmv@freebsd.org> Cc: hackers@freebsd.org Subject: Re: GSoC proposal: Quirinus C library (qc) Message-ID: <CAMqzjeuMa8XOsaXP3S4DmzGscGF_MX7ax8kisAxbwgXVQtT-yg@mail.gmail.com> In-Reply-To: <CAFY7cWD-dPBvMY4UFTB8MnAggt8Zr_oUijuax-WVYkfPBTD0=g@mail.gmail.com> References: <CAMqzjevCoS2qA7jmpPmOXpfzrsD1LzNMJbC8sw-Op-KB-UMhXQ@mail.gmail.com> <CAFY7cWD-dPBvMY4UFTB8MnAggt8Zr_oUijuax-WVYkfPBTD0=g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Julio, I've seen such type handling in libvirt, and I really like it since it provides a great error handling with detailed description. The most reason why I like it is because it enables the possibility to add new error types. The first reason I've been using enum rather than such style is because I wanted a minimal overhead as well as habitual interface (see e.g. POSIX functions returning zero on success). The other reason is that my library is like a bridge between POSIX and Windows: I want universal error code mappings between errno and GetLastError. I know such thing can't be completely universal, but I've always thought that cross-platformness is just when platform-depended code is best hidden, so noone may see it. :-) And thanks for your letter, I think several concepts are incredibly useful and may be adopted to qc library. 2014-03-02 23:50 GMT+04:00 Julio Merino <jmmv@freebsd.org>: > Hello Dmitry, > > As others have mentioned, having such a BSD-licensed library would be > a nice thing, but it's also a huge undertake. I guess that if you > scope the project properly, you'd come out of GSoC with just a tiny > piece of it working. > > But that has already been discussed. The reason I'm replying is > because of the one comment below: > > On Tue, Feb 25, 2014 at 3:24 AM, Dmitry Selyutin <ghostman.sd@gmail.com> > wrote: > > > > 2. Common and universal error type, qc_error. Such errors can be > generated > > from errno values as well as from Windows API errors. > > Almost all functions from qc library except for the three common > functions > > (constructor, destructor, replicator) return qc_error code and set > specific > > qc_errno variable to this code. > > It is now possible to write such constructions: > > if (qc_bytes_import_str(bytes_instance, "Hello, world!")) > > qc_errormsg(qc_errno, "error check"); > > Global variable qc_errno is implemented in terms of multithreading > > applications, it is unique for every running thread. > > For error handling, I'm quite happy with what I did in ATF/Kyua. > Basically, indicating "no error" brings no more overhead than > returning and checking a NULL pointer, whereas indicating "error" can > provide arbitrary amounts of information in dynamically-allocated > structures. There is no global state (i.e. no "errno" style > variables). > > The base library has support to pass around "libc" errors, usage > errors, generic errors and OOM errors. The latter are interesting > because no memory allocation should take place when reporting an OOM > condition. Lastly, client code can define its own error objects if so > wishes to pass around other structured data. > > The code, BSD-licensed, is here: > > https://github.com/jmmv/kyua/blob/master/kyua-testers/error_fwd.h > https://github.com/jmmv/kyua/blob/master/kyua-testers/error.h > https://github.com/jmmv/kyua/blob/master/kyua-testers/error.c > -- With best regards, Dmitry Selyutin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAMqzjeuMa8XOsaXP3S4DmzGscGF_MX7ax8kisAxbwgXVQtT-yg>