relicense 'reallocarray' to LGPLv2+?

Hello Darshit, I'd like to use the 'reallocarray' module[1] for the integer overflow hardening in GnuTLS[2]. Currently the module is licensed under "LGPL" (which I believe means LGPLv3+), while the library part of GnuTLS requires the imported code to be LGPLv2+. Therefore I would like to ask you

removing permissions for long unused accounts?

Hi, On another GNU mailing list, someone is writing: Since I no longer work on I give you permission to remove my git server access (the key). If I ever change my mind about this, we can work out a new solution. Can you please check if I have any other privileged accounts or rights le

update DEPENDENCIES

This patch updates the DEPENDENCIES file. - GCC 2.95 has not been tested in a very long time with gnulib. It's likely that it does not work any more. - Tell where to find working GNU m4 tarballs (since the latest release of GNU m4 does not compile any more on many platforms). - Menti

Re: removing permissions for long unused accounts?

On Sun, Feb 21, 2021 at 1:20 PM Bruno Haible wrote: > > On another GNU mailing list, someone is writing: > > Since I no longer work on I give > you permission to remove my git server access (the key). If I ever > change my mind about this, we can work out a new solution. > > Can you pleas

scratch_buffer: Document the exported API

It looks like the 'scratch_buffer' could be useful to some programs outside of glibc. But you cannot expect that a developer will dig into lib/malloc/scratch_buffer.h, to read definitions full of __libc_ prefixed symbols and libc_hidden_proto declarations, and understand what function names they ca

new module 'string-buffer'

What alternative does gnulib offer to people who use open_memstream()? open_memstream is not portable: https://www.gnu.org/software/gnulib/manual/html_node/open_005fmemstream.html But gnulib cannot provide a drop-in replacement since it would require unportable stream hackery (worse that stdio-im

Re: removing permissions for long unused accounts?

On Sun, Feb 21, 2021 at 10:36 AM Jeffrey Walton wrote: > > On Sun, Feb 21, 2021 at 1:20 PM Bruno Haible wrote: > > > > On another GNU mailing list, someone is writing: > > > > Since I no longer work on I give > > you permission to remove my git server access (the key). If I ever > > change

Re: new module 'string-buffer'

Hi, On 2/21/21 12:55 PM, Bruno Haible wrote: What alternative does gnulib offer to people who use open_memstream()? open_memstream is not portable: https://www.gnu.org/software/gnulib/manual/html_node/open_005fmemstream.html I mentioned this a couple of decades ago. There was no solution, so

Re: implementing fmemopen, open_memstream

Hi Bruce, > I mentioned this a couple of decades ago. There was no solution, so I > rolled my own. > ... > I wanted something that could act like a dropin replacement for > fopen-ing a regular file. There are some quirks (if memory serves), but > it is based on either fopencookie or funopen: W

Re: implementing fmemopen, open_memstream

Hi, On 2/21/21 3:07 PM, Bruno Haible wrote: What do you do on AIX, HP-UX, Solaris, OpenServer, UnixWare, native Windows ? Their stdio implementation does not contain function pointers in structs. One option is to wrap all of the file pointer functions in stdio and have the wrapper look for