From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 2 20:31:44 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BC12ACC4; Sun, 2 Mar 2014 20:31:44 +0000 (UTC) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 220181612; Sun, 2 Mar 2014 20:31:43 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id bs8so2406903wib.12 for ; Sun, 02 Mar 2014 12:31:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=5m7MOICkNV9mgOwZBI0HRmLEdnZ/blmytcXrBwngmX4=; b=Ip1wGSR97slNvBFbEEQWyUhcFmtk4MR5t7xf42FOUYaLgHs4uKxg6O99y4XpUKGnZR 5Qz8u3p3RXAUiGy0wwILlZriiSig3ujcZD6sNRCFzhs+mGPPyJaahC9zIdWsBFCJCzs7 j8igtin1VdTBOM4yoC3VyyHsrC7LNJQ/+VKTgeCBReko54abrNRka1Vp6eJtI+MM0hbn S7Ce6pNyrQYcFZpIWaH26dC/586q5SHycPMXwt0CVEonFyg8md5gHR7gFxptG63UbNBr BMx1AVsSjHzGMOhhSBgRf+z2TDJds/Pex7dEtbXhg4UmrQRrnxcoBeIPjyylvwj+zQsu ZOIg== X-Received: by 10.194.57.140 with SMTP id i12mr11698275wjq.20.1393792302108; Sun, 02 Mar 2014 12:31:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.206.68 with HTTP; Sun, 2 Mar 2014 12:31:22 -0800 (PST) In-Reply-To: References: From: Dmitry Selyutin Date: Mon, 3 Mar 2014 00:31:22 +0400 Message-ID: Subject: Re: GSoC proposal: Quirinus C library (qc) To: Julio Merino Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ghostmansd@gmail.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 20:31:44 -0000 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 : > 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 > 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