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

Re: [Xen-devel] pre_parse and strcmp



>>> On 04.10.14 at 16:57, <dslutz@xxxxxxxxxxx> wrote:
> On 10/03/14 12:22, konrad wilk wrote:
>> On 10/3/2014 12:17 PM, Jan Beulich wrote:
>>>>>> Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> 10/02/14 11:15 PM >>>
>>>> Hit sent to fast [was going to include a patch in this email
>>>> once I had completed this]
>>>>
>>>> My thinking is that the best solution is to have a similar to 
>>>> 'pre_parse'
>>>> function that would convert the in memory buffer from UTF-16 to a 
>>>> normal
>>>> ascii type one.
>>>>
>>>> And hook it up in pre-parse to fix this up.
>>>
>>> I certainly don't mind a patch to deal with UTF-16 config files so 
>>> (in fact already
>>> when I originally coded it I considered this would be a good future 
>>> enhancement).
>>> I'm not, however, convinced that simply converting back to ASCII is 
>>> the proper
>>> solution here. Instead, if we want to allow UTF-16 config files, we 
>>> should do the
>>> conversion the other way around.
>>
>> OK. That will take some time to cobble up.
> 
> A simpler change might be to UTF-8.  (my guess would be that it would 
> then look
> like ASCII and so strcmp would continue to "work".

Since you can't pass UTF-8 strings to EFI services, we'd still need
another translation subsequently, yet obviously we should try to
avoid doing more translation rounds than necessary. Furthermore
that would then raise the question of whether to treat the config
file itself as UTF-8 instead of ASCII (other than UTF-16 ones, UTF-8
ones frequently don't come with a BOM at their start, and hence
can't be told apart without assumptions/prior agreement).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.