(ITS#5324) Access violation on Windows due to %n in format strings

[jeff.lewis@teradata.com]

Full_Name: Jeff Lewis
Version: 2.3.20
OS: Microsoft Windows on IA64
URL: http://msdn2.microsoft.com/en-us/library/ms175782.aspx
Submission from: (NULL) (192.127.94.7)


We (Teradata, formerly NCR) have encountered a small glitch with the latest
Windows SDK and OpenLDAP client tools.  We're getting an access violation where
we did not get one with the older SDK.  Our IA64 builds require the newer SDK
because of codegen issues with the older compilers...but soon, we're going to be
moving to the newer SDK for i386 and x8664 so the problem will begin to crop up
there as well.  Here's the problem:

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.

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.

If you decide to fix this, I'm at your disposal and can provide some testing
support since IA64 platforms are pretty rare.  If you want to get in touch with
me and my email address doesn't work (we're in a spin-off transition right now
so our infrastructure isn't as stable as it should be), you can reach me by
phone at 310-616-2384.