Request for help with PIDL

[Stefan (metze) Metzmacher]

Kamen Mazdrashki schrieb:
> On Thu, Apr 1, 2010 at 00:48, Jelmer Vernooij <jelmer at samba.org> wrote:
> 
>> On Wed, 2010-03-31 at 01:43 +0300, Kamen Mazdrashki wrote:
>>> Hi guys,
>>>
>>> I am trying to create 'drsblobs' python module out of
>>> "librpc/gen_ndr/py_drsblobs.c"
>>> generated file. Unfortunately py_drsblobs.c does not compile :(
>>>
>>> Could you please take a look at py_drsblobs.c, line: 3305 to 3316
>>> static int py_package_PrimaryKerberosString_set_string(PyObject *py_obj,
>>> PyObject *value, void *closure)
>>> {
>>> struct package_PrimaryKerberosString *object = (struct
>>> package_PrimaryKerberosString *)py_talloc_get_ptr(py_obj);
>>> talloc_free(object->string);
>>> if (value == Py_None) {
>>> object->string = NULL;
>>> } else {
>>> object->string = talloc_ptrtype(py_talloc_get_mem_ctx(py_obj),
>>> object->string);
>>> *object->string = talloc_strdup(py_talloc_get_mem_ctx(py_obj),
>>> PyString_AsString(value));
>>> }
>>> return 0;
>>> }
>>>
>>> and "librpc/idl/drsblobs.idl" - line: 337 to 341
>>> typedef struct {
>>> [value(2*strlen_m(string))] uint16 length;
>>> [value(2*strlen_m(string))] uint16 size;
>>>
>> [relative,subcontext(0),subcontext_size(size),flag(STR_NOTERM|NDR_REMAINING)]
>>> string *string;
>>> } package_PrimaryKerberosString;
>>>
>>>
>>> What is wrong here?
>>> Is it the PIDL's Python generator or the IDL definition?
>> Either :-)
>>
>> There is a bit too much magic involved in the "string" variable type
>> that the Python module can't handle without quite a bit of extra code.
>> In this particular situation it eliminates an extra pointer.
>>
>> Ideally we should just replace the "string" variable type with the use
>> of a normal char type.
>>
>>
> I've tried to change the IDL description to this:
> [
>  relative,
>  subcontext(0),
>  subcontext_size(size),
>  flag(STR_NOTERM|NDR_REMAINING),
>  charset(UTF16),
>  string,
>  size_is(size/2)
>  ] uint16 *string;
> Unfortunately no luck (sorry to use the work "luck", but Perl magic looks
> like a Chinese dialect to me).
> When removing "subcontext(0),subcontext_size(size)" though, everything is
> fine!
> I mean 'fine' for Python code generated :)
> Although, following generated look little bit strange:
> object->string = talloc_ptrtype(py_talloc_get_mem_ctx(py_obj),
> object->string);
> PY_CHECK_TYPE(&PyUnicode_Type, value, return -1;);
> object->string = PyString_AsString(PyUnicode_AsEncodedString(value, "utf-8",
> "ignore"));
> It leaves a memory leek, isn't it?
> 
> Anyway, for NDR code I guess it is the "subcontext" spell that makes it to
> parse the blob
> in format described at:
> http://msdn.microsoft.com/en-us/library/cc245503(v=PROT.10).aspx
> 
> So, how should I change the definition (or the Python generator)?

Do you really need it this type for your work?
Otherwise we could just skip it for the python bindings,
I think we have a "nopython" attribute.

If you need it I think we should change the difinition,
but we need to be really careful because I think it was really tricky to
get it right, for the validate case (a ndr_push after a ndr_pull should
generate the exact same result)

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/20100402/51b88cf2/attachment.pgp>