Re: [poll] Resolving readdir_r warning (Re: Showstoppers to 1.7.0?)

Sounds great, good observations. Absent any other opinions, with that resolved, I'm happy to tag and roll this afternoon to begin the release vote. On Fri, Mar 29, 2019, 04:26 Yann Ylavic wrote: > On Fri, Mar 29, 2019 at 5:01 AM William A Rowe Jr > wrote: > > > > Opinions? > > Anyway, our

Re: [poll] Resolving readdir_r warning (Re: Showstoppers to 1.7.0?)

On Fri, Mar 29, 2019 at 5:01 AM William A Rowe Jr wrote: > > Opinions? Anyway, our usage of readdir_r() is no more thread-safe than with the non-_r() version, because of the (struct dirent *)thedir->entry we pass to it (should be either on the stack or allocated for each apr_dir_read() call), or

Re: [poll] Resolving readdir_r warning (Re: Showstoppers to 1.7.0?)

Yes, that patch is option 2... and I would be alright with that choice. Looking for consensus on which way we resolve this. Opinions? On Thu, Mar 28, 2019, 10:55 Yann Ylavic wrote: > On Thu, Mar 28, 2019 at 4:19 PM William A Rowe Jr > wrote: > > > > So... What is our preferred solution as of

Re: [poll] Resolving readdir_r warning (Re: Showstoppers to 1.7.0?)

On Thu, Mar 28, 2019 at 4:55 PM Yann Ylavic wrote: > > On Thu, Mar 28, 2019 at 4:19 PM William A Rowe Jr wrote: > > > > So... What is our preferred solution as of 1.7.0? > > > > 1. Drop readdir[64]_r for readdir[64] always. > > 2. Allow readdir[64]_r with an autoconf toggle, skip detection. > >

[poll] Resolving readdir_r warning (Re: Showstoppers to 1.7.0?)

So to this question, glibc 2.24 is the first release to loudly deprecate readdir_r. https://www.sourceware.org/ml/libc-alpha/2016-08/msg00212.html However, the docs summary mentioned below calls out reasons why readdir_r was never a good thing. So... What is our preferred solution as of 1.7.0?

Re: Showstoppers to 1.7.0?

My working copy just refuses to show the changes but the merge info is there, strange. Taking testencode.c from trunk and it builds great. Test passes. Thank you. cheers On 3/25/2019 4:05 AM, Yann Ylavic wrote: Hi Gregg, On Mon, Mar 25, 2019 at 6:17 AM Gregg Smith wrote: No, r1856096

Re: Showstoppers to 1.7.0?

On Sun, Mar 24, 2019 at 11:14 PM William A Rowe Jr wrote: > > AFAICT the very last 'nit' is our bad habit of using the deprecated > readdir_r()/readdir64_t() functions in modern gcc. Comparing ./configure and > make reminds me I had a kludge to finish in my working 1.7 tree. See >

Re: Showstoppers to 1.7.0?

Hi Gregg, On Mon, Mar 25, 2019 at 6:17 AM Gregg Smith wrote: > > No, r1856096 doesn't help, but thanks. I missed most of the cases actually, better with r1856178?

Re: Showstoppers to 1.7.0?

On 25.03.2019 07:17, Gregg Smith wrote: > Hi Yann, > > No, r1856096 doesn't help, but thanks. > > I think VS just doesn't like these arrays of unknown size. > >     usrc = (unsigned char[]){ }; >     utarget = (unsigned char[]){ }; This is not ANSI C. Visual Studio doesn't support C99 and later

Re: Showstoppers to 1.7.0?

Hi Yann, No, r1856096 doesn't help, but thanks. I think VS just doesn't like these arrays of unknown size. usrc = (unsigned char[]){ }; utarget = (unsigned char[]){ }; It's fine with the ones that are initialized with values like usrc = (unsigned char[]){'f'}; utarget =

Re: Showstoppers to 1.7.0?

AFAICT the very last 'nit' is our bad habit of using the deprecated readdir_r()/readdir64_t() functions in modern gcc. Comparing ./configure and make reminds me I had a kludge to finish in my working 1.7 tree. See

Re: Showstoppers to 1.7.0?

On Fri, Mar 22, 2019 at 6:37 PM Gregg Smith wrote: > > testencode doesn't want to compile on Visual Studio. > A showstopper maybe not but it is nice to run the tests to compare with > previous versions. > > abts.c > testencode.c > testencode.c(91): error C2059: syntax error: '}' >

Re: Showstoppers to 1.7.0?

testencode doesn't want to compile on Visual Studio. A showstopper maybe not but it is nice to run the tests to compare with previous versions. abts.c testencode.c testencode.c(91): error C2059: syntax error: '}' testencode.c(206): error C2059: syntax error: '}' testencode.c(416): error C2059:

Re: Showstoppers to 1.7.0?

On Wed, Feb 27, 2019 at 5:06 PM William A Rowe Jr wrote: > With several new features added to the 1.7 branch, the fixes to the > Netware locking we had deferred, and the proposed correction of > SIGUSR2, I'm wondering what we see as remaining obstacles. > > Do we want to do something about

Re: Showstoppers to 1.7.0?

Yep, all good. Thx! > On Mar 19, 2019, at 3:12 PM, William A Rowe Jr wrote: > > On Tue, Mar 19, 2019 at 1:51 PM Jim Jagielski > wrote: > 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

Re: Showstoppers to 1.7.0?

On Tue, Mar 19, 2019 at 1:51 PM Jim Jagielski wrote: > 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

Re: Showstoppers to 1.7.0?

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

Re: Showstoppers to 1.7.0?

On Tue, Mar 19, 2019 at 12:58 PM Jim Jagielski 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

Re: Showstoppers to 1.7.0?

Hi Greg, On Tue, Mar 12, 2019 at 6:42 PM Gregg Smith wrote: > I finally got time to give this 1.7.0 a try and utterly failed :) > > r1839494 fixed a problem run into on VC when r1816608 added support for > IPv6 link-local address scope/zone mapping. r1839494 requires NT6. > > Our apr.hw is

Re: Showstoppers to 1.7.0?

On Thu, Mar 14, 2019 at 3:02 PM Yann Ylavic wrote: > On Thu, Mar 14, 2019 at 8:38 PM William A Rowe Jr > wrote: > > > > On Thu, Mar 14, 2019 at 10:49 AM Yann Ylavic > wrote: > >> > >> Possibly to resolve APR__T_FMT on system with > >> [std]int[types].h, we could bind to the standard (C99?)

Re: Showstoppers to 1.7.0?

On Thu, Mar 14, 2019 at 3:02 PM Yann Ylavic wrote: > On Thu, Mar 14, 2019 at 8:38 PM William A Rowe Jr > wrote: > > > > On Thu, Mar 14, 2019 at 10:49 AM Yann Ylavic > wrote: > >> > >> Possibly to resolve APR__T_FMT on system with > >> [std]int[types].h, we could bind to the standard (C99?)

Re: Showstoppers to 1.7.0?

On Thu, Mar 14, 2019 at 8:38 PM William A Rowe Jr wrote: > > On Thu, Mar 14, 2019 at 10:49 AM Yann Ylavic wrote: >> >> Possibly to resolve APR__T_FMT on system with >> [std]int[types].h, we could bind to the standard (C99?) format >> PR[dxo..]N, especially since we configure the format based off

Re: Showstoppers to 1.7.0?

On Thu, Mar 14, 2019 at 10:49 AM Yann Ylavic wrote: > Possibly to resolve APR__T_FMT on system with > [std]int[types].h, we could bind to the standard (C99?) format > PR[dxo..]N, especially since we configure the format based off > $ac_cv_sizeof_, so something like: > #define APR__T_FMT

Re: Showstoppers to 1.7.0?

On Wed, Mar 13, 2019 at 9:33 PM Jim Jagielski wrote: > > Just a FYI that compiling httpd trunk (HEAD) against apr-1.7 (HEAD) and > apu-1.6 (HEAD), I get no error messages about APR_OFF_T_FMT issues, so I'm > not exactly sure where these are coming from for macOS Possibly to resolve APR__T_FMT

Re: Showstoppers to 1.7.0?

> On Mar 14, 2019, at 9:06 AM, Stefan Sperling wrote: > > On Thu, Mar 14, 2019 at 07:49:41AM -0400, Jim Jagielski wrote: >> I use maintainer-mode all the time... as I said, building httpd does not >> cause any errors due to APR_SSIZE_T_FMT > > Ah, sorry Jim. I misread your message. No

Re: Showstoppers to 1.7.0?

On Thu, Mar 14, 2019 at 07:49:41AM -0400, Jim Jagielski wrote: > I use maintainer-mode all the time... as I said, building httpd does not > cause any errors due to APR_SSIZE_T_FMT Ah, sorry Jim. I misread your message.

Re: Showstoppers to 1.7.0?

I use maintainer-mode all the time... as I said, building httpd does not cause any errors due to APR_SSIZE_T_FMT > On Mar 14, 2019, at 2:16 AM, Stefan Sperling wrote: > > On Wed, Mar 13, 2019 at 04:22:46PM -0400, Jim Jagielski wrote: >> Just a FYI that compiling httpd trunk (HEAD) against

Re: Showstoppers to 1.7.0?

On Wed, Mar 13, 2019 at 04:22:46PM -0400, Jim Jagielski wrote: > Just a FYI that compiling httpd trunk (HEAD) against apr-1.7 (HEAD) and > apu-1.6 (HEAD), I get no error messages about APR_OFF_T_FMT issues, so I'm > not exactly sure where these are coming from for macOS > > % uname -a > Darwin

Re: Showstoppers to 1.7.0?

Just a FYI that compiling httpd trunk (HEAD) against apr-1.7 (HEAD) and apu-1.6 (HEAD), I get no error messages about APR_OFF_T_FMT issues, so I'm not exactly sure where these are coming from for macOS % uname -a Darwin jimsys.local 18.2.0 Darwin Kernel Version 18.2.0: Thu Dec 20 20:46:53 PST

Re: Showstoppers to 1.7.0?

On Tue, Mar 12, 2019 at 02:21:46PM -0500, William A Rowe Jr wrote: > Rereading the APR_CHECK_TYPES_COMPATIBLE logic, I misread it. We test and > successively pass ssize_t as int compatible, followed by retesting and > passing ssize_t as long compatible, so the resulting > APR_SSIZE_T_FMT pattern

Re: Showstoppers to 1.7.0?

On Wed, Mar 13, 2019 at 11:47 AM Yann Ylavic wrote: > > On Fri, Mar 8, 2019 at 9:19 PM William A Rowe Jr wrote: > > > > On Wed, Feb 27, 2019 at 5:06 PM William A Rowe Jr > > wrote: > >> > >> Do we want to do something about de-prioritizing sysv semaphores > >> on linux by default with the

Re: Showstoppers to 1.7.0?

On Fri, Mar 8, 2019 at 9:19 PM William A Rowe Jr wrote: > > On Wed, Feb 27, 2019 at 5:06 PM William A Rowe Jr wrote: >> >> Do we want to do something about de-prioritizing sysv semaphores >> on linux by default with the 1.7.0 release? > > Comments? I know some distributors already hack around

Re: Showstoppers to 1.7.0?

I think we basically agreed to keep 0.9 at stasis. And expected the next major prereq jump after 1.x at 2.0. I'm not worried about maintaining support, but we should have a serious dialog about going all Unicode/NT and ripping out all of the Win 32-bit 9x code in the 2.0 trunk, and choosing a new

Re: Showstoppers to 1.7.0?

I finally got time to give this 1.7.0 a try and utterly failed :) r1839494 fixed a problem run into on VC when r1816608 added support for IPv6 link-local address scope/zone mapping. r1839494 requires NT6. Our apr.hw is still targeting NT5 which has been EOL for eons now, 6.0 also as Vista

Re: Showstoppers to 1.7.0?

On Tue, Mar 12, 2019 at 1:59 PM William A Rowe Jr wrote: > > One obvious flaw I had missed in my earlier list, the problem with > maintainer mode strictness and our APR_OFF_T_FMT warnings. > > I think the patch is as simple as prioritizing int over long... which > would be the same logic already

Re: Showstoppers to 1.7.0?

On Fri, Mar 8, 2019 at 2:19 PM William A Rowe Jr wrote: > > I'd like to give this question a few more days, and finally lock down > our 1.7.0 candidate sometime later next week. > One obvious flaw I had missed in my earlier list, the problem with maintainer mode strictness and our APR_OFF_T_FMT

Re: Showstoppers to 1.7.0?

On Wed, Feb 27, 2019 at 5:06 PM William A Rowe Jr wrote: > With several new features added to the 1.7 branch, the fixes to the > Netware locking we had deferred, and the proposed correction of > SIGUSR2, I'm wondering what we see as remaining obstacles. > These two appear to be in good shape.

Re: Showstoppers to 1.7.0?

On Fri, 1 Mar 2019 12:04:34 -0600 William A Rowe Jr wrote: > My question was entirely limited to apr, I hadn't yet considered > pushing for an apr-util release. Hehe. It occurred to me to ask that, but only after my reply yesterday night. :) > Perhaps resolving apr 1.7 this month (what I've

Re: Showstoppers to 1.7.0?

On Fri, Mar 1, 2019 at 5:01 AM Yann Ylavic wrote: > On Thu, Feb 28, 2019 at 12:06 AM William A Rowe Jr > wrote: > > > > Any other concerns ahead of 1.7.0? > > There are some backports I need to revert, the dynamic linking (as > opposed to dynamic loading) of apr_crypto libraries -1'ed by Graham

Re: Showstoppers to 1.7.0?

On Thu, Feb 28, 2019 at 12:06 AM William A Rowe Jr wrote: > > Any other concerns ahead of 1.7.0? There are some backports I need to revert, the dynamic linking (as opposed to dynamic loading) of apr_crypto libraries -1'ed by Graham (see discussion in r1833359 and r1833421 threads), and thus the

Re: Showstoppers to 1.7.0?

> On 27 Feb 2019, at 23:06, William A Rowe Jr wrote: > > With several new features added to the 1.7 branch, the fixes to the > Netware locking we had deferred, and the proposed correction of > SIGUSR2, I'm wondering what we see as remaining obstacles. Did I backport the xml build option for

Re: Showstoppers to 1.7.0?

On 2/27/2019 5:06 PM, William A Rowe Jr wrote: With several new features added to the 1.7 branch, the fixes to the Netware locking we had deferred, and the proposed correction of SIGUSR2, I'm wondering what we see as remaining obstacles. Any other concerns ahead of 1.7.0? If I may propose: 

Showstoppers to 1.7.0?

With several new features added to the 1.7 branch, the fixes to the Netware locking we had deferred, and the proposed correction of SIGUSR2, I'm wondering what we see as remaining obstacles. I'd like to proceed with addressing the symlink vs. "other" reparse tag questions raised for Windows, and