convert_string + librpc/ndr (via openchange) == fail

[sean finney]

Hi Stefan,

On Tue, May 17, 2011 at 09:32:01AM +0200, Stefan (metze) Metzmacher wrote:
> >> If you know the character set globally, then setting the dos charset
> >> will help, but I'm guessing this isn't as simple as that.  As we have
> >> the iconv handle code (and tests using the handles), I think the correct
> >> fix is to reinstate that onto the ndr structures, but in an optional way
> >> (understanding the limitations around enclosed structures etc).
> > 
> > Like I said above, this isn't a global setting, it can different between
> > different MAPI items depending on the configuration of the senders, AFAICT.
> 
> Then using uint8_t array seems to be the only option.
> 
> Or the code page also encoded somewhere in the request?

The MAPI item has a number of properties which define the codepage to
be used for the property in question (this is all AFAICT, from digging
in the code and reading the MS specs).

Example:

A message has the subject stored in a property PR_SUBJECT/PidLidSubject.  The
codepage of this property is determined by another property, 
PR_MESSAGE_CODEPAGE/PidTagMessageCodepage.  Other properties may use the
latter as well, and some specific properties have their own (i.e. the message
body has a dedicated property).  Additionally, there's some fall-back logic
in the spec that says first to try this codepage, and then fall back to the
folder-specified codepage (yet another property), and then the profile's or
server's codepage (i think, and these would also be additional props).

So for a client that wants to send a batch request containing a list of
different properties etc, this could be a bit of a chicken and egg scenario,
or at least would involve a bit of extra convoluted logic to split up
the batch of requests into several smaller batches.

And ultimately, since we're only talking about 8-bit null terminated strings,
I don't see what's wrong with just passing that along to the caller, and allow
them to handle it as they see fit (they may, for example, internally convert
them to unicode before displaying them, allowing the client to reply in
unicode).  If ndr_pull_string isn't the right function for that (which it
sounds like it isn't), I guess there'd need to be an addition to the API and
any code templating tools like pidl to allow pulling a null-terminated
uint8 buffer.



	sean