On 19/01/16 11:11, Heiko Schlittermann wrote: > Graeme Fowler <graeme@???> (Di 19 Jan 2016 11:51:57 CET):
>> On 18 Jan 2016, at 18:22, Jeremy Harris <jgh@???> wrote:
>>>
>>> You could rewrite that "ldap_get_values()" call, for which there's
>>> a "deprecated" note in my (Fedora 23) include file, with
>>> "ldap_get_values_len()" - which supports a binary interface for
>>> arbitrary byte-sequences. You'll need struct berval (lber.h)
>>> fore the pointer+length.
>>
>> And this, of course, was the right answer. It seems that some shorter (as yet undefined) responses are happily handled as char responses even though they're binary, the longer ones most definitely aren't. It's fairly likely that this issue has existed for some time and we've simply never been alerted to it!
>
> Just for my understanding…
> the, value of the attribute starts with a '\0' byte?
If it does - or, indeed, has embedded NULs - Exim just
isn't going to deal kindly with it/them. Exim strings
are C-style nul-terminated. Everywhere. About the
only places that are special are mail message bodies
and TLS certificates.
--
Jeremy
