On Wed, Jun 29, 2022 at 4:47 PM William A Rowe Jr <wr...@rowe-clan.net> wrote: > > This change does introduce an API change, and a somewhat possibly dangerous > structure size alteration, and seems to be out of bounds for apr 1.7.x branch.
AFAICT, this change only touches internal/opaque structures.. Are you talking about apr__pool_unmanage()? If so it was later removed in r1897210. About this change particularly, it fixes serious bugs in APR threads, just run the tests with r1884102 (before this commit), APR_POOL_DEBUG (to ease reproduction) and under ASan (Address Sanitizer, -fsanitize=address), or maybe it was httpd's tests. I can't remember the details and travis does not seem to keep builds history that far (Dec 2020) so I can't point you to the stack traces / reports. I do remember that period where we started to run ASan builds though (in httpd and later APR), this led to a series of fixes in APR, including this one.. > > Anyone using a build crossing runtimes between apr 1.7.0 and 1.7.1 may > experience > unintended side-effects. Anyone running apr-1.7.x without these fixes and using threads is kind of in UB land. > > While it's true that include/arch and include/private are not > considered generally > supported, folks are known to use them, and macros may cause the library to > bleed internals. Really? We don't install these headers, and they are opaque precisely so that we can change them without breaking users. If users copy private headers for their use cases, shouldn't they take the burden of maintaining their codebase (depending on that) when those headers change? This can't be on us.. By making such impracticable policies for revision changes (semver sense), we are going to simply not fix anything but trivial changes without bumping minor, and no one would/should care about the old (though still "maintained") minor versions. What's the point of releasing 1.7.1 then? Let's go with 1.8.0 only, simpler (less maintenance) and better for everybody.. Regards; Yann.
