PIDL: Problem generating strings without charset parameter

[Jelmer Vernooij]

Simply ignoring the encoding is the wrong thing to do here.

You could write custom pull/push/print functions for this field that
took into account the windows codepage specified elsewhere in the
struct, e.g. like the custom handlers in ndr_exchange.c.

Jelmer

On Thu, Oct 15, 2015 at 12:17:51PM +0200, Javier Amor Garcia wrote:
> We have already a lot of generic rpc interface code generated from a IDL
> file. We try to avoid writing and maintaining it manually just for the
> encoding of this strings.
> 
> On 10/14/2015 07:17 PM, Jelmer Vernooij wrote:
> >In that case, why do you need pidl to create chars? You can't use these
> >strings in unknown encoding directly I assume. You'll get chars when you
> >convert the string to the local encoding using e.g. talloc_convert_String.
> >
> >Jelmer
> >
> >On 14 October 2015 4:48:13 PM GMT+01:00, Javier Amor Garcia
> ><jamor at zentyal.com> wrote:
> >
> >        If this is for a field that actually has text in it, what
> >        encoding is
> >
> >    it in?
> >
> >    I don't know the encoding until runtime, normally is a windows code
> >    page, which is given in another member of the struct.
> >    So I cannot do any generic check or conversion with it.
> >
> >    Cheers,
> >
> >    Javier
> >
> >    On 10/14/2015 05:37 PM, Jelmer Vernooij wrote:
> >
> >        On Tue, Sep 08, 2015 at 01:19:39PM +0200, Javier Amor Garcia wrote:
> >
> >            I am using the PIDL generator and I have the problem is that
> >            if I remove
> >            the 'charset' parameter for a string. the generated code is
> >            always a
> >            uint8* types and I want instead to get a 'const char*'.
> >
> >        That is working as intended. If there is no known character set,
> >        these
> >        are just raw bytes - as pidl doesn't know using what encoding to
> >        interpret them
> >        and convert them to Samba's local character set.
> >
> >        If this is for a field that actually has text in it, what
> >        encoding is it in?
> >        If this is for a field that has non-text data, why do you need
> >        it to be a "char
> >        *"?
> >
> >        Cheers,
> >
> >        Jelmer
> >
> >
> >
> >
> 
> 
> -- 
> Javier Amor García - Developer
> 
> Zentyal - Active Exchange - www.zentyal.com
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20151015/6390c298/signature.sig>