Under OSX/macOS, whether off_t and/or size_t are long long or long depends on compile time and the actual platform being compiled for. To have a universal *.h file, you need those checks for __LP64__ that are determined during the build of whatever is *using* APR, and not so much during when APR itself is built. If I adjust to bypass all Darwin specifics and allow the fall-through, it actually *creates* a defect on macOS depending on which version we are building on and which version of Xcode being used.
As it is, right now, with the __APPLE__ macro fix I added to apr-*, all is good from OSX 10.7 (the oldest I have) thru 10.14 using both official Apple Xcode cc/clang and MacPorts gcc. > On Mar 19, 2019, at 2:30 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > On Tue, Mar 19, 2019 at 12:58 PM Jim Jagielski <j...@jagunet.com > <mailto:j...@jagunet.com>> wrote: > > Hi Bill, can you let me know what issues you saw? Last I checked, the > Darwin stuff in configure.in <http://configure.in/> and apr.h.in > <http://apr.h.in/> hasn't been touched, nor an issue, > in ages, except for the recent DARWIN pre-defined cpp macro hiccup. > > Hi Jim - see stsp's many posts over the months r.e. BSD. It had the same > observed issue, and your patch obviously was no help, because BSD is > not -D APPLE. > > With the corrections tested by Stefan now, BSD will fall through to using > the %lld pattern. Actually, it fixes the observed defect on OSX too, even > with the APPLE patch omitted, but we needed to correct all the details > covered with your fix specific to OSX, not just the one %ld quirk. > > Sure, the Darwin stuff has some weirdness, but that was closed > long ago and was/is due to APR being, after all, a library, and must > be portable to all platforms that OSX/macOS are being built for despite > how the library itself was built. Even some of Apple's own *.h files > include these work-arounds. If we're doing something wrong, let's > fix it. Thx! > > We definitely want to clean things up, but I'd consider it unwise to > make very many changes in apr 1.x. Lots of edge cases can probably > be dropped by getting the tests right in the first place in autoconf, but > let's save most of that for APR 2? > > The new patches are for BSD and every architecture other than OSX > that grows quirky about %ld vs %lld where long and long long are > presently the same byte width, nothing to do with the better APPLE > determination you caught last week. > > Stefan indicates there is a lingering problem with APR_INT64_T_FMT > which is bizarre because why would we ever pair long with %lld or > long long with %ld? But we did, and I'm looking for that defect still. > >
