On Tue, Feb 25, 2014 at 3:39 PM, Dmitry Selyutin <[email protected]> wrote: > 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. > First I've sent it to FreeBSD only since I didn't know that OpenBSD is > accepted into GSoC too, so the rest is a copy of the original letter to > FreeBSD mailing list with small changes.
Hi Dmitry ! Also, please have a look at the list of projects at http://www.openbsdfoundation.org/gsoc2014.html Since you like hacking on libs, have you considered looking at this project and the SD/MMC stack project : http://www.openbsdfoundation.org/gsoc2014.html#usb-userland-xfer http://www.openbsdfoundation.org/gsoc2014.html#sdmmc It's nice to have a suggestion, but please pay attention to the _current_ problems that OpenBSD developers are interested to solve. (Go through the tech archieves). If you find something that you would like to solve, and it has been discussed quite a few times on tech, I would suggest that you mail the developer and ask for more information :-) Good luck. > > 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 instance 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 am I writing such letter to BSD world? I'm pretty sure that every BSD > system 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 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 matter. 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! > > > P.S. Since OpenBSD is a Canadian organization, I'd like to take a moment to > thank Canadian ice-hockey players for a great game in Sochi they've shown. > :-) I'd really glad to see something like Summit Series 1972, but I'm > afraid that after Sochi Canadian team is invincible. Still hope Russian > team will ever show the same level. :-) > > -- > With best regards, > Dmitry Selyutin -- This message is strictly personal and the opinions expressed do not represent those of my employers, either past or present.
