GSoC proposal: Quirinus C library (qc)

Thu Feb 27 09:34:34 UTC 2014

W dniu 2014-02-26 21:02, Fernando Apesteguía pisze:
> On Wed, Feb 26, 2014 at 8:05 PM, Łukasz Wójcik <lukasz.wojcik at zoho.com>wrote:
>
>> W dniu 2014-02-25 09:24, Dmitry Selyutin pisze:
>>
>>   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!
>>>
>>>
>> Hi Dmitry,
>>
>> I'd like to say I personally like the idea of having glibc counterpart in
>> FreeBSD (and possibly other OSes). It's not quite sure though whether
>> you're looking for help with development or review ? Perhaps with something
>> else ?
>>
>
> I suppose you mean _glib_ instead of glibc (our glibc counterpart is our
> libc in base).
>
> The project sounds nice although a lot of features (like the error
> treatment, multithreading support...) are already present in glib (and they
> are very well tested).
>
> Cheers.

Yes, of course, I meant glib. As you know it's much much more feature 
rich than standard libc, e.g. xml parsing, regular expressions, 
key-value parsers and many, many more.

>
>
>>
>> Sincerely,
>> -ŁW
>>
>>
>> _______________________________________________
>> freebsd-hackers at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>>
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>