On Tue, Mar 19, 2019 at 12:58 PM Jim Jagielski <j...@jagunet.com> wrote:
> > Hi Bill, can you let me know what issues you saw? Last I checked, the > Darwin stuff in configure.in and 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.
