Joe Orton wrote: > > This is an API extension so can't be backported to the 1.2.x branch (per > the versioning rules).
Which explains why you responded to the original post how? In a rare turn, this doesn't actually introduce any API. I was very explicit in pointing this out, and asking a week ago for the feedback of the developers. Let's be clear; 1.2.8 was not portable behavior; violated APR, but was the API for Win32. 1.2.11 restored portability to the Unix model; broke a few, far between applications of APR on Win32. 1.2.12 proposes to retain the restored portability in all but the most unusual edge cases who presumed our API for Win32 was correct. I'd be happy to keep this, remove the APR_NO_FILE flag, hint to that application developer of the hardcoded constant, and let them roll their dice for expecting APR to provide grok that constant. With APR 1.3/httpd 2.4 they would be able to get rid of the const value cruft. If you want to scroll back and respond to the final analysis thread named; "Solution to apr stdio/msvc crt/service handles and logging" ... I took the time to thoroughly dissect the issue, if you want to weight in, that would be the thread to do it on. We have two purposes to serve on the 1.2.x branch; let people expect portable behaviors, and attempt to avoid breaking people who weren't looking at the portability of behaviors. This is the only compromise I could arrive at. It doesn't require changes to functions, or arg types, or return types. It's strictly the introduction of a MACRO which will not 'harm' any existing app. If you want to veto the patch; propose an alternative that serves both the purpose of portability and the purpose of those who relied on the older non portable behavior. Bill
