IMNSO opinion, this seems like a somewhat safe 1.8 change. What you want to ask is how someone who "discovers" apr.so.1 (.8) would react with 1.7 code, and if that's clean and using only public API's, it makes sense to me. That's not the case for other changes, but for this one it shouldn't shock anyone who doesn't explicitly ask for -lapr against libapr.so.1.7
On Thu, Jun 30, 2022 at 7:39 AM Yann Ylavic <ylavic....@gmail.com> wrote: > > On Wed, Jun 29, 2022 at 4:49 PM William A Rowe Jr <wr...@rowe-clan.net> wrote: > > > > The eventual change still is present for apr > > 1.8 adopters. > > > > Thoughts? ylavic are you willing to revert? > > It seems that no one is using apr_mmap_create() with an offset != 0 or > the bug would have been reported (PR 65158 proved to be a cifs > filesystem bug finally). Well, apr_bucket_file reads can use an mmap > offset if planets misalign still, and that's possibly why we had quite > some issues for "EnableMMap on" in httpd (IIRC), but since it was > never nailed to this bug it usually ends with "please EnableMMap => > off".. > So let's revert, if something comes up around this, it's probably > another case where I'll first ask: can you reproduce with apr-1.8? > > For 1.8.x then (we can fix it there right?), I'd rather we revert this > change and r1887508 to merge trunk's r1887060 and r1887506 directly > (i.e. without the API workaround-try of this 1.7.x merge). > That is, add the "poffset" field to (the end of) apr_mmap_t and be > done with no tricks. But since I'm not sure what we can or not do with > a minor bump I'll ask, can we do that? > > Regards; > Yann.
