[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 1/4] unicode: New mod_utf8_codepoint()
From: |
Laszlo Ersek |
Subject: |
Re: [Qemu-devel] [PATCH 1/4] unicode: New mod_utf8_codepoint() |
Date: |
Fri, 22 Mar 2013 12:46:47 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130307 Thunderbird/17.0.3 |
On 03/22/13 10:23, Markus Armbruster wrote:
> Laszlo Ersek <address@hidden> writes:
>> On 03/14/13 18:49, Markus Armbruster wrote:
>>> +{
>>> + static int min_cp[5] = { 0x80, 0x800, 0x10000, 0x200000, 0x4000000 };
>>> + const unsigned char *p;
>>> + unsigned byte, mask, len, i;
>>> + int cp;
>>> +
>>> + if (n == 0) {
>>> + *end = (char *)s;
>>> + return 0;
>>> + }
>>
>> This is a special case (we return the code point U+0000 after looking at
>> zero bytes); we can probably expect the caller to know about n==0.
>
> We could make it an error instead. What's your gut feeling?
(If the question still stands -- maybe it doesn't any more, considering
future handling of '\0':) I guess this function would be called in a
loop, with increasing "s" and decreasing "n" values. "end" can only be
checked after the first call. If you write a loop that checks "end" in
the controlling expression, then accepting n==0 without error is useful.
If you write a loop that checks "n" in the controlling expression, then
refusing n==0 is OK. I'd probably write the latter kind of loop (I like
pre-testing more), but I can't say in general :)
Laszlo
[Qemu-devel] [PATCH 4/4] qjson: to_json() case QTYPE_QSTRING is buggy, rewrite, Markus Armbruster, 2013/03/14
Re: [Qemu-devel] [PATCH 0/4] Fix JSON string formatter, Blue Swirl, 2013/03/17