Re: Remaining breakage on apr-1.7.x branch

After deep study of the whole ring strict alias issue, I've come to
the conclusion that
the -resulting- binary is effectively the same, and my test case was
swapping the
apr .so files between builds of httpd 2.4.54 / apr 1.7.0 and httpd
2.4.x/ apr 1.7.x.
Running httpd test, no errors were introduced, all binaries loaded and ran fine.
Someone building Subversion might want to repeat that exercise.

So this was entirely a work-around to ensure the grammar didn't escape notice
when types and values were switched around in ways that a compiler might
over-optimize. There were instances where -O3 could break apr at one point,
and I'm wondering if this might have been that root cause?

I think we can accept this very unusual (for a stable release branch)
contortion,
since code correctly compiled on either 1.7.0 or 1.7.branch appear to accomplish
the same and are binary-stable, only using different syntaxes to get there.

Any final thoughts before we simply release 1.7 branch as-is?

Bill


On Wed, Sep 7, 2022 at 11:06 AM Eric Covener <[email protected]> wrote:
>
> On Thu, Jul 28, 2022 at 12:59 PM William A Rowe Jr <[email protected]> wrote:
> >
> > Hello friends and collaborators,
> >
> > I'm still rather certain this change is ABI and API contract-breaking
> > on the apr-1.7.x branch, which holds the project hostage for providing
> > a well-understood security fix on the legacy branch. Such things
> > can't persist, our individual maintenance branches must also observe
> > semver, such that anyone could consume a maintenance branch and
> > not be API nor ABI broken against the prior sub-version release;
> >
> > https://github.com/apache/apr/compare/1.7.0...1.7.x#diff-86c28ef8e95257a8d60ce73f3262290e91fc5ca3eb722144a6c99559ddf717cf
> >
> > I'd propose a radical solution, either all of include/* excluding most
> > of private / arch/* have no adverse effects on a rebuild, or we revert
> > the whole branch to the last stable release, in 7 days. Allow a 7 day
> > window to reintroduce critical and desired changes that don't break
> > our dev guidelines;
> >
> > https://apr.apache.org/versioning.html.
> >
> > All other questions were resolved at least 4 weeks ago, as can
> > be observed from include/* changes which alter the incremental
> > consumer's observations, github makes this simple;
> >
> > https://github.com/apache/apr/compare/1.7.0...1.7.x#
> >
> > So I think we are nearly ready 14 days from now to tag 1.7.1
> > and solve this conundrum. If it can be proven than the existing
> > 1.7.0 or 1.7.1 builds would be entirely compatible and not break
> > developer's expectations when deployed against either 1.7.1
> > or 1.7.0 in the next 7 days, my objection is withdrawn and we
> > will tag this code in one week, not waiting for 2 weeks.
> >
> > Who wants to help prove up or down that it should persist and
> > work out the back-out as needed? Otherwise I ask the project
> > member's permissions to work from a new 1.7.x-rebuild branch
> > for the following week based on 1.7.0, and replace 1.7.x with
> > the 1.7.x-rebuild branch one week later.
>
> Should we just back out r1896748 (ring strict aliasing thing) out at
> this stage?  I think the radical solution is too labor intensive and
> unlikely to progress.