On 19/01/16 11:11, Heiko Schlittermann wrote: > Graeme Fowler <[email protected]> (Di 19 Jan 2016 11:51:57 CET): >> On 18 Jan 2016, at 18:22, Jeremy Harris <[email protected]> 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 -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
