Re: POC: updated LDAP support for apr-util 1.7

2023-09-19 Thread Graham Leggett via dev
On 19 Sep 2023, at 11:34, Ruediger Pluem wrote: >> /* For DSO builds, export the table of entry points into the apr_ldap DSO > > In the end I think this effort only makes sense if we find a way to get LDAP > back into trunk. > I cannot remember if these enhancements would be enough to address

Re: [VOTE] release apr-util-1.6.2-rc2 as apr-util 1.6.2

2023-01-24 Thread Graham Leggett via dev
On 24 Jan 2023, at 02:02, Noel Butler wrote: > This is a result of apr-util 1.6 STILL NOT patched for mariadb or mysql 10 > plus > > https://bz.apache.org/bugzilla/show_bug.cgi?id=61517#c5 > If you prepare a > patch for 1.6 I can take

Re: apr_dbm API and BerkleyDB

2023-03-12 Thread Graham Leggett via dev
Hi, Let’s try this again. apr_dbm API. Regards, Graham —

apr_dbd API and BerkleyDB

2023-03-12 Thread Graham Leggett via dev
Hi all, BerkleyDB is gone in SUSE and going away in RHEL[1]. How does this practically affect the apr-dbd API? We support gdbm, but that’s GPLv3. Do we need a new implementation? [1] https://access.redhat.com/articles/6464541 Regards, Graham —

Release apr-util v1.7.0

2023-03-12 Thread Graham Leggett via dev
Hi all, I’d like to see a release of apr-util v1.7.0. Does anyone know of any problems outstanding that might need fixing? Regards, Graham —

POC: updated LDAP support for apr-util 1.7

2023-04-18 Thread Graham Leggett via dev
Hi all, The following patch adds ldapi:// (LDAP over unix domain socket) support to apr-util. It is part of a wider cleanup covering the following: - Add apr_ldap_t to hide the native LDAP type. - Add apr_ldap_initialize() with URL support, allowing us to do ldapi://, including proper pool

Re: Cross compiling APR

2023-05-02 Thread Graham Leggett via dev
On 02 May 2023, at 08:16, Stephen Webb wrote: > Does cross compilation work in theory? > > Am I wasting my time attempting to add support for cross compilation to the > conan package manager? As I recall the cross complication I got to work was for the benefit of openwrt, which a while back

Re: svn commit: r1914814 - in /apr/apr/trunk: CHANGES encoding/apr_escape.c include/apr_escape.h test/testescape.c tools/gen_test_char.c

2023-12-22 Thread Graham Leggett via dev
On 21 Dec 2023, at 06:11, Ruediger Pluem wrote: >> +APR_DECLARE(apr_status_t) apr_escape_json(char *escaped, const char *str, >> +apr_ssize_t slen, int quote, apr_size_t *len) > > Shouldn't we provide a length for the escaped buffer to be able to do some > sanity checking against

Re: getopt error message with a bare "-"

2023-12-02 Thread Graham Leggett via dev
On 28 Nov 2023, at 07:46, Daniel Sahlberg wrote: > Subversion is using APR's apr_getopt_long for command line processing. > > A user tried to supply "-" for the filename with the intention of using stdin > (Subversion has support for this in our code). However the user got the > following

Re: svn commit: r1917047 - in /apr/apr/trunk: CHANGES buffer/ buffer/apr_buffer.c build.conf include/apr_buffer.h test/Makefile.in test/Makefile.win test/NWGNUaprtest test/abts_tests.h test/testbuffer

2024-04-16 Thread Graham Leggett via dev
Hi all, > +/** > + * Structure for efficiently tracking a buffer that could contain > + * a zero terminated string, or a fixed length non zero string. > + */ > +typedef struct > +{ > +/** pointer to the data, which could be a string or a memory block. */ > +union { > +char *str; >

Re: svn commit: r1917050 - in /apr/apr/trunk: CHANGES crypto/apr_crypto.c dbd/apr_dbd.c dbm/apr_dbm.c include/private/apu_internal.h util-misc/apu_dso.c

2024-04-17 Thread Graham Leggett via dev
On 17 Apr 2024, at 08:07, Ruediger Pluem wrote: >> Modified: apr/apr/trunk/util-misc/apu_dso.c >> URL: >> http://svn.apache.org/viewvc/apr/apr/trunk/util-misc/apu_dso.c?rev=1917050=1917049=1917050=diff >> == >> ---

Re: svn commit: r1917047 - in /apr/apr/trunk: CHANGES buffer/ buffer/apr_buffer.c build.conf include/apr_buffer.h test/Makefile.in test/Makefile.win test/NWGNUaprtest test/abts_tests.h test/testbuffer

2024-04-17 Thread Graham Leggett via dev
On 17 Apr 2024, at 07:52, Ruediger Pluem wrote: >> +APR_DECLARE(apr_buffer_t *) apr_buffer_str_make(apr_pool_t *pool, >> +char *str, apr_ssize_t len) >> +{ >> +apr_buffer_t *buf; >> +apr_int64_t size; >> +apr_size_t slen; >> + >> +

Re: svn commit: r1917047 - in /apr/apr/trunk: CHANGES buffer/ buffer/apr_buffer.c build.conf include/apr_buffer.h test/Makefile.in test/Makefile.win test/NWGNUaprtest test/abts_tests.h test/testbuffer

2024-04-17 Thread Graham Leggett via dev
On 17 Apr 2024, at 08:12, Ruediger Pluem wrote: >> I need some advice on handling Windows 32 bit. apr_int64_t for size is too >> big, and tests are failing. >> >> Technically apr_ssize_t is the right size, but the definition of ssize_t is >> [-1, SSIZE_MAX]. I need a signed very big number.

Re: svn commit: r1917082 - /apr/apr/trunk/buffer/apr_buffer.c

2024-04-18 Thread Graham Leggett via dev
On 18 Apr 2024, at 13:15, Yann Ylavic wrote: > Indeed at least APR_BUFFER_MAX and buf->size of should be of the same > signedness. APR_BUFFER_MAX represents the size limit visible outside the API. This is always positive. buf->size is an internal implementation detail. This is invisible. The

Re: svn commit: r1917082 - /apr/apr/trunk/buffer/apr_buffer.c

2024-04-18 Thread Graham Leggett via dev
On 18 Apr 2024, at 12:14, Ruediger Pluem wrote: >> +#define APR_BUFFER_MAX APR_SIZE_MAX/2 > > Why no longer APR_OFF_MAX? As was pointed out, apr_off_t is always 64 bits would still break on Windows. Inside the API, we need a very big, signed, value, and apr_off_t is perfect. Outside the API,

Re: svn commit: r1917082 - /apr/apr/trunk/buffer/apr_buffer.c

2024-04-18 Thread Graham Leggett via dev
On 18 Apr 2024, at 15:57, Yann Ylavic wrote: >> could be: >> APR_DECLARE(apr_status_t) apr_buffer_str_set(apr_buffer_t *buf, >> char *str, apr_size_t len) >> { >>if (len == APR_BUFFER_STRING) { >>len = str ? strlen(str) : 0; >>} >>

Re: RFC: APR 2.0 modularization

2024-04-22 Thread Graham Leggett via dev
On 20 Apr 2024, at 11:38, Ivan Zhakov wrote: > In APR 2.0 we merged APR-Util **project** to APR. Which is IMHO a good thing. At the time, and with time and hindsight, I never understood what the point was at combining APR and APR-util. The reason is because... > But we also merged everything

Re: RFC: APR 2.0 modularization

2024-04-22 Thread Graham Leggett via dev
On 22 Apr 2024, at 12:52, Ivan Zhakov wrote: >> The question is, is it worth it for such a marginal change? >> Have you looked in to the practicalities and verified no major stumbling >> blocks, >> bearing in mind that developer effort tends to be thin on the ground? >> > > Take the Apache

Re: svn commit: r1917266 - in /apr/apr/trunk: buffer/apr_buffer.c include/apr_buffer.h test/testbuffer.c

2024-04-22 Thread Graham Leggett via dev
On 22 Apr 2024, at 14:13, Ruediger Pluem wrote: >> @@ -322,7 +287,17 @@ APR_DECLARE(int) apr_buffer_ncmp(const a >> return 1; >> } > > There was a proposal from Yann to simplify the above block to > >if (!src) { >return dst ? 1 : 0; >} >if (!dst) { >

Re: svn commit: r1917082 - /apr/apr/trunk/buffer/apr_buffer.c

2024-04-22 Thread Graham Leggett via dev
On 18 Apr 2024, at 17:07, Yann Ylavic wrote: > If so maybe: > > typedef struct > { >union { >char *str; >void *mem; >} d; > #if APR_SIZEOF_VOIDP == 8 > # define APR_BUFFER_SIZE_WIDTH 63 > #else > # define APR_BUFFER_SIZE_WIDTH 31 > #endif > apr_size_t

Re: svn commit: r1917050 - in /apr/apr/trunk: CHANGES crypto/apr_crypto.c dbd/apr_dbd.c dbm/apr_dbm.c include/private/apu_internal.h util-misc/apu_dso.c

2024-04-22 Thread Graham Leggett via dev
On 22 Apr 2024, at 14:05, Ruediger Pluem wrote: >>> Now the caller needs to allocate memory even if it is not interested in the >>> error or if there is no error at all. >>> Wouldn't it be better to add an apu_err_t **err instead (which can be NULL) >>> and in case of an error allocate an >>>

Re: RFC: APR 2.0 modularization

2024-04-22 Thread Graham Leggett via dev
On 22 Apr 2024, at 14:30, Ivan Zhakov wrote: > Can you confirm why xlate/iconv cannot be moved to a module? (No expectation > for you to do such a move, just want to understand what makes it impossible). >> > I think it can be done in theory, but I see potential problem: API should be >

Update doxygen site

2024-04-22 Thread Graham Leggett via dev
Hi all, Updating the doxygen site at https://apr.apache.org/docs/apr/2.0/modules.html - is it as simple as replacing the files under https://svn.apache.org/repos/asf/apr/site/trunk/docs/docs/apr/trunk/ or is there more to the process than that? Regards, Graham --

Re: svn commit: r1917266 - in /apr/apr/trunk: buffer/apr_buffer.c include/apr_buffer.h test/testbuffer.c

2024-04-24 Thread Graham Leggett via dev
On 24 Apr 2024, at 14:03, Yann Ylavic wrote: >> -#define APR_BUFFER_MAX APR_SIZE_MAX/2 >> +#define APR_BUFFER_MAX (APR_SIZE_MAX/2-1) > > It seems that the ->size does include the terminating NUL byte so > APR_BUFFER_MAX could be APR_SIZE_MAX/2 no? Why -1 here? > Also maybe ->size should be

Re: svn commit: r1917099 - /apr/apr/trunk/test/testldap.c

2024-04-18 Thread Graham Leggett via dev
On 18 Apr 2024, at 08:48, minf...@apache.org wrote: > URL: http://svn.apache.org/viewvc?rev=1917099=rev > Log: > Add the LDAP test case. I am getting a failure on Windows about a missing symbol, I am assuming the changes to cmake are incomplete. Would it be possible for someone to look at the