GSoC proposal: Quirinus C library (qc)

[Dmitry Selyutin]

Hi Jordan, Łukasz, Fernando,

thanks for your kind replies! There is a lot of questions, I will try to
answer everything, if I miss anything, just let me know. :-)

I will start with some fixes proposed by Łukasz. If you look into
src/core/error/posix.c, you will find exactly what you have talked about
(not sure if I have already pushed it though). I am going to switch to such
style everywhere, that is just a matter of time. And yes, you are right
with variable name :-)

To Fernando: yes, I know about error treatment. The main goal of qc_error
type is to provide more descriptive error codes than we have (e.g. we have
EILSEQ, but that is not enough to know the real error in Unicode handling),
also I wanted to provide a conversion algorithm that aims to make a mapping
between POSIX and Windows (errno vs GetLastError).

Now it is time for a long response to Jordan. First of all, I realize
comprehensiveness of this project: no one will write Boost in three months.
:-) Of course that will be just the beginning. The reason why I decided to
try and join GSoC with this project is that I thought it may be to find
someone who understands better both C and FreeBSD needs to guide me. I need
a wise and experienced mentor who may give good advice or help me to select
right way.

As for the portability in terms of modules, I am planning to separate the
project into modules such a qc/core.h|-lqc_core, qc/codecs.h|-lqc_codecs,
etc. Of course I am afraid that sooner or later one module may require
another one (e.g. file streams may require qcsys module, which contains
qc_path-related functions); I am trying to avoid such problems even if
sometimes it requires code duplication. You may see endianness detection
inside qc_codecs_u16_decode, where I have stated that I would rather detect
endianness here rather that call qc_sys_byteorder. I know that we must
avoid code duplication; I think it is where we have to choose from two
evils.

As for strings, I will not use UTF-16 since it provides more problems
rather than solutions. If I provide a function which accepts char* or char
const* argument, I imply that such function uses only ASCII (may be I will
change ASCII to UTF-8). Encoding is used only if a user has requested it
explicitly; the only place where I have made exception is system path since
path requires to be in UTF-16 on Windows. That is the reason why qc_path
requires qc_codecs-related functions.

i18n is one of the most complicated parts and is one of the main reasons
why I have made a decision to write this library. We have ICU, which is –
just in my opinion – an ugly, dead-born monster mainly due to mix of C, C++
and Java concepts. It is well tested though, so we can just take all the
best from it and never touch the rest.

Since I have always thought that deeds speak louder than words (facta sunt
potentiora uerbis). And I am pretty sure that good C library which was made
by FreeBSD may persuade someone to migrate to it from Windows as it
sometimes happens with people who have got addicted to bash. :-) At least,
even if we drop Windows support (it seems, however, to be a bad idea to
me), I think that we must support POSIX-compliant systems at least.

As for GCD, I will think about it. That is the situation where we need to
choose between new dependancy and reinventing a new wheel. Honestly, I have
always thought that threads suck; I guess if this concept had been created
nowadays, it would have not been such a bullshit.

Thank you all for your replies again, especially to Jordan. If I missed
anything, please remind me. Looking forward to your replies!

Best regards,
Dmitry Selyutin