From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 27 15:39:47 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C0F8B4CD for ; Thu, 27 Feb 2014 15:39:47 +0000 (UTC) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4E0E91175 for ; Thu, 27 Feb 2014 15:39:47 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id r20so840675wiv.10 for ; Thu, 27 Feb 2014 07:39:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=cS6kWp9vxXJEXoqV3LhghMBCE5ZmxJIm5qVrNwSdEvY=; b=aTgIFAVKiziLSppADRO26A96muW3sClPrP5C1OgU00XuxvqMqKDk7Dz0BhmD63lzfP 1u3nzqUcNJFc63uer9f3v6h5oKQsijl5GNg7yizjYKWhYZL2QpOtZtzs5BPMjSn0CUPp Ia3geJODDwB3UpxnzLZ7sjwOV+1CMikrCVr5drEW0K+QtNkL+fEOUz7BR58y0nggZMH8 PGeNbopIUzK8dC8Njsd4clpVmjrEayeRKDVGcr8qJWL/l3K0FwZCNToly7bhsJI48kZJ uDhcYaC2ky+CHaWzrrkqX8QI2TGuoTf9ce7jhb6gY4FfPcsGUWZnGD2iZHrnHgkOAuAg EJPg== MIME-Version: 1.0 X-Received: by 10.194.110.135 with SMTP id ia7mr8432649wjb.5.1393515585675; Thu, 27 Feb 2014 07:39:45 -0800 (PST) Received: by 10.194.206.68 with HTTP; Thu, 27 Feb 2014 07:39:45 -0800 (PST) Received: by 10.194.206.68 with HTTP; Thu, 27 Feb 2014 07:39:45 -0800 (PST) Date: Thu, 27 Feb 2014 19:39:45 +0400 Message-ID: Subject: Re: GSoC proposal: Quirinus C library (qc) From: Dmitry Selyutin To: hackers@freebsd.org, Jordan Hubbard , =?UTF-8?B?xYF1a2FzeiBXw7NqY2lr?= , =?UTF-8?Q?Fernando_Apestegu=C3=ADa?= X-Mailman-Approved-At: Thu, 27 Feb 2014 16:36:19 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: Thu, 27 Feb 2014 15:39:47 -0000 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