bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: prepare vasnprintf for Unicode strings


From: Eric Blake
Subject: Re: prepare vasnprintf for Unicode strings
Date: Mon, 11 Jun 2007 13:47:38 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

Bruno Haible <bruno <at> clisp.org> writes:

> 
> The Unicode string I/O - essentially a *printf directive 'U' that accepts
> Unicode strings as arguments, but also the ability to produce Unicode strings
> rather than char* strings - requires some modifications to the vasnprintf
> code.

Hmm - cygwin (and I assume BSD in general, since newlib borrowed BSD's stdio) 
supports %U to mean %lu.  But since it is not standardized, I guess your 
extension of %U to mean something resembling %S is okay.

> +     /* A null pointer is an invalid argument for "%U", but in practice
> +        it occurs quite frequently in printf statements that produce
> +        debug output.  Use a fallback in this case.  */
> +     if (ap->a.a_u8_string == NULL)
> +       {
> +         static const uint8_t u8_null_string[] =
> +           { '(', 'N', 'U', 'L', 'L', 0 };

Typo.  Missing ')'.  copy-n-pasted twice more.

> + /* A parsed directive.  */
> + typedef struct
> + {
> +   const uint16_t* dir_start;
> +   const uint16_t* dir_end;
> +   int flags;
> +   const uint16_t* width_start;
> +   const uint16_t* width_end;
> +   size_t width_arg_index;
> +   const uint16_t* precision_start;
> +   const uint16_t* precision_end;
> +   size_t precision_arg_index;
> +   uint16_t conversion; /* d i o u x X f e E g G c s p n U % but not C S */

what about a A F?

> + #if ENABLE_UNISTDIO
> +             /* The unistdio extensions.  */
> +             case 'U':
> +               if (flags >= 16)
> +                 type = TYPE_U32_STRING;
> +               else if (flags >= 8)
> +                 type = TYPE_U16_STRING;
> +               else
> +                 type = TYPE_U8_STRING;
> +               break;
> + #endif

I started getting confused reading flags with raw integer comparisons here (and 
this patch didn't introduce it, the code was already like that).  Maybe it 
would be better to make an enum of conversion widths, and do bitwise 
comparisons instead of >= of magic numbers?  But I don't see any bugs in what 
you've done, just readability concerns, so don't feel obligated to rewrite it.

-- 
Eric Blake






reply via email to

[Prev in Thread] Current Thread [Next in Thread]