From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 25 08:24:39 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 76394B70 for ; Tue, 25 Feb 2014 08:24:39 +0000 (UTC) Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 303151AC6 for ; Tue, 25 Feb 2014 08:24:39 +0000 (UTC) Received: by mail-ve0-f173.google.com with SMTP id jw12so54757veb.32 for ; Tue, 25 Feb 2014 00:24:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:from:date:message-id:subject:to:content-type; bh=fFozdjgs31DtntOR+N72OXabt2dghI7k7EMKjskVHJc=; b=hLw8YiHS4Xn5Tg8lzI5hoKSrAf+6EVNWHolrYAvSSlX37sSLxVl5B4GfiqKogCEmf4 cVLyJw84tV0fPS9erxdE05/f4BY3+TfgXovSl7Lj1NcXMi2gDxwn+xyVk0RjZdm0wUze yqeW+Wj0NPO5YeW5yG1ZKWvhxb/V3NtuPFlZbb6nJAht0ddjnKqZ3LMVWmsD4fuqnAWZ biVWw//a7DHZWu5qA4OBbvyP+pwkH+/KHBUm8uPbMjr30OTVT9JsaAUhJKzKaL9lkX4W 7ehn0hkjlXz+eLojyhQ/86gKhCa+rSiXrXJOxb60j9E9/eiH487BoVe4TnlmSw4g6MtD l6SA== X-Received: by 10.58.172.132 with SMTP id bc4mr39606vec.45.1393316678103; Tue, 25 Feb 2014 00:24:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.249.197 with HTTP; Tue, 25 Feb 2014 00:24:17 -0800 (PST) From: Dmitry Selyutin Date: Tue, 25 Feb 2014 12:24:17 +0400 Message-ID: Subject: GSoC proposal: Quirinus C library (qc) To: hackers@freebsd.org X-Mailman-Approved-At: Tue, 25 Feb 2014 12:48:04 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 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: Tue, 25 Feb 2014 08:24:39 -0000 Hello everyone! My name is Dmitry, I'm 22 years old student from Lomonosov Moscow State University of Russia. This message is addressed mainly to C connoiseurs, yet I think other people may find it interesting. It's a GSoC proposal. It's a pity that for language like C we generally don't have something universal like Boost, so we have to implement some common functions from scratch or introduce new dependencies. We have Glib, which is used mainly by Gnome developers (though it is a standalone library) and LGPL-ed, which is not as liberal as Boost's license. We also have APR, which seems to be a bit more comprehensive and convenient, yet it is not so well-known as Glib. I'm in process of implementing a something like Boost for ANSI C (though I don't pretend this library to share Boost's comprehensiveness). Several ideas I find useful are: 1. Strict and universal interface. Each function begins with qc_ prefix, followed by type if function is type-related. Most of types (except enum-typedef'ed ones) have three common functions (replace _type_ with the necessary type name, e.g. _bytes_): a. Constructor: void * qc_type_construct(void). Allocate object instance and initialize it to default value. b. Destructor: void qc_type_destruct(void * pointer). Deallocate memory allocated for object and its members. c. Replicator: void * qc_type_replicate(void const * pointer). Replicate object, copying its data to new allocated object, i.e. clone. Most of types also have _import_ and _export_ functions, which allow to fill allocated object with the desired data (e.g. fill bytes array from null-terminated char string) or export data to another type. Almost all enum-typedef'ed types also have _import_ and _export_ functions to retrieve a key value corresponding to string. 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. 3. Clear distinction between byte and Unicode strings (qc_byte and qc_ucs types for characters, where qc_byte has exactly 8-bit width and qc_ucs has exactly 32-bit width). Charsets are just enumeration, e.g. QC_ENCODING_UTF8, QC_ENCODING_ISO_8859_4, etc., yet it is possible to lookup the desired encoding using qc_encoding_import. If encoding is known under several names, they are handled alltogether, i.e. QC_ENCODING_ASCII will be returned for any of "ASCII", "iso-ir-6", "ANSI_X3.4-1968", "ISO646-US", etc. Register doesn't matter. Two new types, qc_bytes and qc_unicode are provided, in order to store binary and Unicode data. It is possible to store null characters inside such objects. It is similar to C++ string and C++ vector classes. 4. Universal file system path type. It is possible to achieve cross-platformness using such path types, i.e. it is possible to make directories, links, symlinks, remove files, directories, etc. regardless of platform path API. 5. i18n support must be embedded with qc library. Locales, timezones, day and months names, etc. must be provided too, in several forms if necessary. i18n functions work with qc_unicode type, so charset conversion problems won't exist. 6. Multithreading support if platform permits it. On POSIX we use pthreads, on Windows we use its API for multithreading. I'm also thinking about green threads implementation. Thread local storage is already implemented, yet there is still a lot work to be done with threads, mutexes, etc. 7. Multiprecision arithmetics. I'm using GMP to achieve it, yet I'm planning to switch to something BSD-like or to implement it from scratch (that probably would be better, since library doesn't introduce any dependencies except GMP). 8. Ternary logic almost everywhere. Being fan of Russian Setun computer, I've started this library as implementation of ternary logic operations. When I've realized that there is still much to be done in other fields, I've already concluded that ternary logic is suitable for a wide set of other operations, e.g. comparison, determining type of strings, endianness, etc. I think that I'll leave type qc_trit, since I've found it extremely useful. 9. A lot of other things to be done, such as unified I/O streams which provide compression/transformation filters, protocols, math library, etc. Why I'm writing such letter to FreeBSD? I'm pretty sure that FreeBSD highly needs such library, since we try to use BSD-like license and yet to implement things that exist in GNU world. The most common example is GNU readline library, yet I think there is a lot of libraries that we reimplemented just to let some projects suit BSD philosophy. We can make a good library, which can be used a lot in different projects, yet it will field everyone like Boost. The nature of C language itself helps us to keep this library much more tiny than Boost library; I also think that we can limit our support with POSIX-(almost-)compatible platforms and Windows. I've already done a lot of work, but it is hard to make decisions without advice or discussion, so I've thought about to enter GSoC this year like I did two years ago when I've reimplemented gnulib-tool for FSF. This project is much more interesting for me, since I want to upgrade my C skills, get known BSD world better and provide a good cross-platform library which may be useful to almost everyone. Since I've already finished my volunteer's job in Sochi (I've worked as technologist volunteer), I'm really want to make something new for other people to be useful. If you are interested in my project, here is repository at GitHub: https://github.com/ghostmansd/quirinus. I guess I'll later rename it to https://github.com/ghostmansd/qc, yet it doesn't matters. If you're interested in my previous GSoC work, you can find it here: https://github.com/ghostmansd/gnulib-python. If you want to get to know me better from any side (my philological studies in Lomonosov Moscow University, GSoC participation, Sochi volunteer job, etc.), you can write me a email; I'd be very glad. Thanks for reading such a long letter! -- With best regards, Dmitry Selyutin