[SCM] Samba Shared Repository - branch master updated

[Stefan (metze) Metzmacher]

Andrew Bartlett schrieb:
> On Tue, 2010-03-23 at 01:52 +0000, Jelmer Vernooij wrote:
>> On Tue, 2010-03-23 at 12:06 +1100, Andrew Bartlett wrote:
>>> On Mon, 2010-03-22 at 23:09 +0100, Jelmer Vernooij wrote:
>>>> Can you please send patches to the registry in for review first?
>>>>> +			if (data.length % 2 == 0) {
>>>>> +				/* The data is provided as UTF16 string */
>>>>> +				ret2 = convert_string_talloc(mem_ctx, CH_UTF16, CH_UTF8,
>>>>> +							     (void *)data.data, data.length,
>>>>> +							     (void **)&val->data,&val->length,
>>>>> +							     false);
>>>>> +				if (!ret2) {
>>>>> +					talloc_free(msg);
>>>>> +					return NULL;
>>>>> +				}
>>>>>
>>>> ^^ This isn't necessarily true ? What if there is an uneven number of 
>>>> characters in a UTF-8 string? In that case the length of that string 
>>>> would be even.
>>> I think mdw is right here.  If the data is not a multiple of 2 bytes,
>>> how is converting from UTF16 to UTF8 ever going to work, so why bother
>>> trying?  (if we try, we may just fill the logs with DEBUG() message). 
>> Not trying as UTF16 if length % 2 != 0 seems appropriate, but /only/
>> trying UTF16 and not trying UTF8 if length % 2 == 0 seems inappropriate.
> 
> Matthias:
> 
> Where does 'data' come from here?  From the wire or from the DB?  
> 
> If it comes from the wire, is UTF8 data ever valid on the wire for this
> protocol, or is this a 'UCS2' buffer that happens to be able to contain
> either UCS2, UTF16 or binary crap without error (but no real client puts
> UTF8 there)?

Registry values are just DATA_BLOBs and the type is just a hint for the
client nothing more! That's what Günthers registry/winreg torture tests
have found. So we should not convert anything and just pass the blob.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100323/95a06001/attachment.pgp>