GSoC proposal: Quirinus C library (qc)

[Dmitry Selyutin]

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 at 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 at 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