Date: Thu, 27 Feb 2014 19:39:45 +0400 From: Dmitry Selyutin <ghostman.sd@gmail.com> To: hackers@freebsd.org, Jordan Hubbard <jkh@turbofuzz.com>, =?UTF-8?B?xYF1a2FzeiBXw7NqY2lr?= <lukasz.wojcik@zoho.com>, =?UTF-8?Q?Fernando_Apestegu=C3=ADa?= <fernando.apesteguia@gmail.com> Subject: Re: GSoC proposal: Quirinus C library (qc) Message-ID: <CAMqzjevahZowxWv0gH=Z8jjQdzGsEaA5U_VB-zsLCcwtoWkvxA@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Hi Jordan, =C5=81ukasz, 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 =C5=81ukasz. 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 =E2= =80=93 just in my opinion =E2=80=93 an ugly, dead-born monster mainly due to mix o= f 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAMqzjevahZowxWv0gH=Z8jjQdzGsEaA5U_VB-zsLCcwtoWkvxA>