[email protected] wrote: > > The previous paragraph acknowledges that we aren't worried if somebody > codes against in-flux APIs in that apr-util packaged with httpd 2.3.4. > What is the problem scenario here? How can the exchange of > apr-util-1.4.0-dev with apr-util 1.4.1 hurt unless the user has some > code that relies on in-flux APIs?
On some platforms (windows) the library will fail to load if the number of args to an apr_fn(x,y,z) signature change. Win32, for example, will decorate the link symbols with the number of bytes of stack args, e.g. apr_initialize is 'apr_initial...@0'. But on most platforms, such a change in the number of args is silently harmful. Similarly, for Graham's work on the apr_crypto_t structure, moving the apr_crypto_driver_t element or adding the *error pointer in the middle of the existing declarations will silently slaughter a provider compiled under 1.4.1+++ but running under 1.4.0-dev.
