Can you give some more context, perhaps an example?

Also, is there a particular reason this bug is private ?

In the current argument based client bindings a caller needs to pass in
an allocated string if it's an [out,ref] array with charset() used.

But the caller can't know how long the string will be in "unix" charset.
Currently we have very strict tests before we do a memcpy of the returned
string into the caller provided buffer.

void function([in] uint32 length,
              [out,ref,size_is(length)] [charset(UTF16)] uint16 *string
              );

In this example we currently generate this.

void function(struct some_context *, uint32_t length, const char *string);

Notice length is the length of uint16 units on the wire,
but the caller has no chance to know how long the string will
be in unix charset. so we can only generate truncated string
or return an error if the returned low level string can't
be copied completely into the given string.

The new code should look like this.

void function(struct some_context *, uint32_t length, const char **string);

This way function can just allocate the string and return it.

This bug still exists but it has become less blocking as we simply were able to switch using the struct based pidl generated rpc client calls (where we do not suffer from this issue). So, effectively, we dont currently use any other rpc calls in samba3 where this problem is an issue. Lowering severity and making this not a blocker issue for 3.6.0.

Moving PIDL bugs into Samba as we do not release PIDL separately.