In libraries/libldap/url.c, function ldap_url_desc2str, there are a

couple of

sprintfs that use %n in their format strings to return position information. The latest Windows SDKs have heavily deprecated %n and its use now results in an unfortunate access violation and process crash.

ldap_url_desc2str calls desc2str, which is where the sprintfs are.

There's actually only one in an if/else in that function.

This is the same for the latest 2.3 libldap and 2.4 libldap

but this doesn't really answer your question.

We've added a call to "_set_printf_count_output(1)" in libraries/libldap/init.c function ldap_int_initialize() to re-enable %n so we're sufficiently worked around for the moment. We're happy with our own workaround so we're not asking for any kind of quick turnaround on this issue. If you want to fix this, please do so in your own time and in your own way. You can consider this a courtesy report only.

If you decide not to fix this, please let me know because we'll need to add a formal test case to our regression suites to make sure we don't resurrect the issue when we upgrade our OpenLDAP clients.

The msdn.microsoft.com website has the details of their proprietary function and SDK versions where it's required in case you want to use our approach. I included the URL so that you can get to it directly without going through MSDN's searching. My own opinion is finding a way to do without the %n is probably better and would result in fewer ifdefs in the code (always a plus in my book) and less Microsoft specific code lurking around to bite us later.

We did pull down 2.3.39 and our tech that looked at the code tells me the %n's are still there and there's no _set_printf_count_output call so we think the problem still exists in the latest version. Give me a virtual slap if I've got this wrong.