Eric Covener writes:
> Hi all,
>
> Please find below the proposed release tarball and signatures:
>
> https://dist.apache.org/repos/dist/dev/apr/
>
> I would like to call a VOTE over the next few days to release
> this candidate tarball apr-1.7.4-rc1 as 1.7.4:
[X] +1: It's not just good, it's
Eric Covener writes:
> Hi all,
>
> Please find below the proposed release tarball and signatures:
>
> https://dist.apache.org/repos/dist/dev/apr/
First time voting for an APR release, but isn't apr-1.7.4-rc1-win32-src.zip
missing from the set of artifacts?
I think that it was present during
Yann Ylavic writes:
> Do we want to include r1909117 in 1.7.4 (to call abort() instead of
> assert() in apr_base64 when NDEBUG)?
> Sorry for the lateness, but should there be an -rc2 (or in any case..).
If I recall correctly, APR 1.7.x doesn't have apr_base64, because it is a
part of APR-util
Eric Covener writes:
> I will RM but it might be a bit piecemeal between now and the weekend.
> At the mercy of a lot of inflexible $bigco stuff.
>
> Hoping to improve a little this time by porting more of icings amazing
> httpd release work.
Awesome, thanks!
Regards,
Evgeny Kotkov
Christophe JAILLET writes:
> +1 for me.
>
> Looking at 1.7 and 1.6 it seems it was done this way in previous releases.
Committed in https://svn.apache.org/r1909103
Thanks,
Evgeny Kotkov
Christophe JAILLET writes:
> If we remove things that are part of previous 1.7.x releases, shouldn't
> Changes for APR 1.7.[23] be added here instead?
Hm, since these are the 1.8.x CHANGES maybe it'd be better to drop the 1.7.1,
1.7.2 and 1.7.3 entries from here and just link to
Hi everyone,
Unfortunately, one of the fixes in APR 1.7.3 that was authored by me has
caused a significant regression, where writing to files opened with both
APR_FOPEN_APPEND and APR_FOPEN_BUFFERED now may not properly append
the data on Windows. The issue has been reported in [1].
Compared to
Yann Ylavic writes:
> So possibly something like the below:
>
> Index: encoding/apr_base64.c
> ===
> --- encoding/apr_base64.c(revision 1908764)
> +++ encoding/apr_base64.c(working copy)
> @@ -20,8 +20,27 @@
> * ugly 'len'
Yann Ylavic writes:
> +#undef NDEBUG /* always abort() on assert()ion failure */
> +#include
Sorry for being late to the party, but I think there are a few problems with
the "#undef NDEBUG" line:
1) The debug implementation of an assert() may print a diagnostic message,
for example to stderr.
Yann Ylavic writes:
> Oh, and the loop seems to have been removed later in r1828509
> "apr_file_read: Optimize large reads from buffered files on Windows"
> (backported to 2.4.x in r1902379 too).
> So Windows is doing the right thing now (not unix), right?
Yes, AFAICT unix still uses the
Yann Ylavic writes:
> But the short-write argument stands, if Windows never short-writes
> then the implicit full-write is unnecessary, but if it does
> short-write then apr_file_write() has to return it too (for the user
> to know), so in both cases the loop has to stop when written <
>
Yann Ylavic writes:
> Why would buffered reads always be full reads (i.e. until the given
> size of EOF)?
>
> For apr_file_read() I don't think this is expected, users might want
> read() to return what is there when it's there (i.e. they handle short
> reads by themselves), so implicit full
12 matches
Mail list logo
