Hi,
When we enabled running tests under valgrind in libidn2 [0] we found
out this issue, which involves the unistring/iconv part of the gnulib
code:
==3644== Conditional jump or move depends on uninitialised value(s)
==3644==at 0x4E3EBCC: freea (malloca.c:134)
==3644==by 0x4E40C1D: mem_ic
On Fri, Nov 25, 2016 at 7:17 PM, Bruno Haible wrote:
> Hi Nikos,
>
> For gnulib support, please CC bug-gnulib, don't write to me in private.
> The mailing list is the main instrument to share know-how and reach agreement
> among gnulib developers.
>
>> I was prevented from installing these two mo
Hi,
The recent patch which added the option 3orGPLv2 didn't modify the
license text to reflect the 3orGPLv2 license. This patch attempts to do
just that (it's a bit ugly but the result seems ok).
regards,
Nikos
From a052732ba0f8fe7e298d02d60943834117855077 Mon Sep 17 00:00:00 2001
F
On Sat, 2016-05-28 at 23:53 -0700, Paul Eggert wrote:
> Nikos Mavrogiannopoulos wrote:
> >
> > secure_getenv()
> > has no (known to me) meaning for windows, and that's why I'd expect
> > that call there to behave as getenv().
> I'm afraid that this doe
> > Nikos Mavrogiannopoulos wrote:
> > The current implementation doesn't have any support for windows,
> > meaning that environment variables will be unusable on that OS.
>
> Why is that the wrong thing to do? Can you give an example? Why would
> an application in
From: Nikos Mavrogiannopoulos
Date: Sat, 28 May 2016 19:48:51 +0200
Subject: [PATCH] secure_getenv: modified to operate as getenv() in windows
Signed-off-by: Nikos Mavrogiannopoulos
---
lib/secure_getenv.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/lib/secure_geten
On Fri, 2016-05-13 at 09:41 -0700, Paul Eggert wrote:
> On 05/13/2016 09:31 AM, Nikos Mavrogiannopoulos wrote:
> >
> > Hi,
> > The attached patch replaces the call of exit() with _exit() in
> > signal
> > handlers. exit() is not one of the functions that can
Hi,
The attached patch replaces the call of exit() with _exit() in signal
handlers. exit() is not one of the functions that can be cleanly called
from a signal handler (see signal(7))
regards,
Nikos
From ef0bdd39fb814ed2af7170cce19dae6a57213677 Mon Sep 17 00:00:00 2001
From: Nikos
On Tue, 2013-12-03 at 17:39 +0100, Ludovic Courtès wrote:
> Pádraig Brady skribis:
>
> > The speed of md5 and sha* hashes has lagged a bit in gnulib.
> > So to address that and to take advantage of the architecture
> > specific assembly used in libcrypto, the attached gnulib patch
> > allows proj
Hello,
Few weeks ago I received a complaint on one of the libraries I work
on, that I use GPLv3 files to generate files that are supposedly
LGPLv2. This was on the gnulib part of the library so I reported it
here [0] and sent a patch on [1] to what I understood the bug was. As
this was not patches
On Thu, 2013-11-21 at 12:08 -0800, Paul Eggert wrote:
> Thanks, but the file doc/error.texi explains why the error module
> does not depend on the progname module.
Hello,
My main issue is that I don't use error() and I have issues with it
because some module (xalloc-die) uses it. In fact does xal
>From 53ae3b6b60328b541a1621bf1f5974c8fe5d4dec Mon Sep 17 00:00:00 2001
From: Nikos Mavrogiannopoulos
Date: Thu, 21 Nov 2013 20:43:35 +0100
Subject: [PATCH] error() uses program_name.
---
modules/error | 1 +
1 file changed, 1 insertion(+)
diff --git a/modules/error b/modules/error
in
It seems that error.c uses _GL_ATTRIBUTE_FORMAT_PRINTF but it doesn't
depend on anything that defines it.
regards,
Nikos
>From 0646d27d063b097758b23081f8881765c7093fa8 Mon Sep 17 00:00:00 2001
From: Nikos Mavrogiannopoulos
Date: Thu, 21 Nov 2013 19:58:47 +0100
Subject: [PATCH] The _G
On Tue, Nov 12, 2013 at 10:28 AM, Nikos Mavrogiannopoulos
wrote:
>>> It seems that gnulib-tool installs files in build-aux like
>>> "snippet/c++defs.h" that are under GPLv3+, even if the --lgpg=2 flag
>>> is specified. If these headers are GPLv3+ shoul
On Mon, Nov 11, 2013 at 9:51 PM, Eric Blake wrote:
> On 11/11/2013 01:34 PM, Nikos Mavrogiannopoulos wrote:
>> Hello,
>> It seems that gnulib-tool installs files in build-aux like
>> "snippet/c++defs.h" that are under GPLv3+, even if the --lgpg=2 flag
>> is
On Mon, 2013-11-11 at 13:51 -0700, Eric Blake wrote:
> On 11/11/2013 01:34 PM, Nikos Mavrogiannopoulos wrote:
> > Hello,
> > It seems that gnulib-tool installs files in build-aux like
> > "snippet/c++defs.h" that are under GPLv3+, even if the --lgpg=2 flag
Hello,
It seems that gnulib-tool installs files in build-aux like
"snippet/c++defs.h" that are under GPLv3+, even if the --lgpg=2 flag
is specified. If these headers are GPLv3+ shouldn't they be skipped in
that case?
regards,
Nikos
Hello,
Would it be possible that the following modules are licensed under
LGPLv2.1+ instead of LGPLv3+? They are (conditionally) used by the
gnutls library and would be nice if we could avoid the LGPLv3+ switch.
opendir
readdir
closedir
iconv_open-utf
best regards,
Nikos
On 07/03/2013 11:36 PM, Eric Blake wrote:
[...]
> on earlier license requests, and given that the code is ultimately
> assigned to the FSF, I've gone ahead and made these changes.
I don't know if it is applicable in that specific case, but I had been
explicitly told by Stallman that GNU maintai
Hello,
I've recently started a project and while looking for functionality
that didn't exist in gnulib I've find CCAN at [0] which is pretty
similar to gnulib. It contains code snippets to be used in programs
under liberal licenses. Some of the code there is similar to code used
in Linux kernel (s
I received the following bug report for gnulib.
http://savannah.gnu.org/support/?108150
The patch in the report is attached.
regards,
Nikos
--- gnutls-3.1.2/gl/string.in.h.orig 2012-04-13 00:05:11 +0400
+++ gnutls-3.1.2/gl/string.in.h 2012-10-03 14:28:32 +0400
@@ -683,7 +683,7 @@
On Mon, Oct 1, 2012 at 8:46 PM, Jim Meyering wrote:
>> Any update on that? Do you plan to include it?
> I went to deal with the mechanics of adding it and noticed a few details.
> What do you think about hash_pjw_no_mod or hash_pjw_bare
> as the function name? They convey more meaning than the
On 09/27/2012 10:19 PM, Nikos Mavrogiannopoulos wrote:
> Updated.
Hello,
Any update on that? Do you plan to include it?
regards,
Nikos
On 09/27/2012 08:55 PM, Jim Meyering wrote:
>> And having said that, here is that function.
> ...
>> Subject: [PATCH] Added hash-pjw-s.
> ...
> Hi Nikos,
> Thanks for working on this.
Updated.
regards,
Nikos
>From 14a0d1ac40de4fcd16dff605a0fdf86a8227520f Mon Sep 1
On Thu, Sep 27, 2012 at 12:12 PM, Nikos Mavrogiannopoulos
wrote:
> 4. hash_pjw_s_no_tablesize()
> We can eliminate (2), but still there are 3 variants of the same
> function. Maybe it is better to keep only (4) and (1) for backwards
> compatibility, and anybody who wants to do the %
On Thu, Sep 27, 2012 at 9:07 AM, Paul Eggert wrote:
> It might be better to not have the tablesize
> arg, at least in a variant of the function.
This would result to 4 functions instead:
1. the original hash_pjw()
2. hash_pjw_no_tablesize()
3. hash_pjw_s()
4. hash_pjw_s_no_tablesize()
We can eli
r if requested in hash_pjw().
regards,
Nikos
>From 82b53fda2a73bbdbd7483fb0a74dc00ada7a0b64 Mon Sep 17 00:00:00 2001
From: Nikos Mavrogiannopoulos
Date: Thu, 27 Sep 2012 08:42:55 +0200
Subject: [PATCH 2/2] If tablesize is zero then return the full h.
---
lib/hash-pjw.c |5 -
1 file c
Hello,
Would it be possible to relicense hash-pjw under LGPLv2+ or v3+? It
is quite a useful function and I'd like to use it in gnutls and
libtasn1 (I could re-implement it but I'd like to avoid that if
possible). Also would it be possible to have a version that works with
non-null terminated stri
On 05/06/2012 12:34 PM, Bruno Haible wrote:
> Niels Möller wrote:
>> One possibility might be to not define the types at all, unless the
>> gnulib application explicitly asks for them. Lots of applications want
>> uint32_t, and I imagine a lot fewer have any need for int_fast*_t.
> Yes. For this r
Hello,
I've noticed that some systems define AF_LOCAL in sys/socket.h while
others AF_UNIX and most define both. Could gnulib provide both
definitions (e.g. by this patch) to simplify their usage on various
platforms?
regards,
Nikos
diff --git a/lib/sys_socket.in.h b/lib/sys_socket.in.h
index c91
l Message
Subject: Re: [W32] gnutls-2.12.18 fixes
Date: Tue, 10 Apr 2012 00:45:58 +0400
From: LRN
To: bug-gnu...@gnu.org
On 09.04.2012 19:55, Nikos Mavrogiannopoulos wrote:
> On 04/09/2012 04:13 PM, LRN wrote:
>
>>>> W32 support in GNUTLS 2.x deteriorated a little bit since my
>>
Hello,
I received this patch in gnutls for ioctl.c.
regards,
Nikos
diff --git a/lib/ioctl.c b/lib/ioctl.c
index 2e51c92..e6ba46b 100644
--- a/lib/ioctl.c
+++ b/lib/ioctl.c
@@ -49,6 +49,9 @@ rpl_ioctl (int fd, int request, ... /* {void *,char *} arg */)
# include "fd-hook.h"
/* Get _get_osfhandl
On 01/30/2012 10:29 PM, Jim Meyering wrote:
> Hi Nikos,
> Have you considered pre-filtering the data you pass to the base64-decoding
> function? We considered what you're proposing when adding the
> --ignore-garbage option to the command-line base64 program:
Hello,
Could also be done, but sin
Mon Sep 17 00:00:00 2001
From: Nikos Mavrogiannopoulos
Date: Mon, 30 Jan 2012 22:16:47 +0100
Subject: [PATCH] Base64 decoding is tolerant on carriage returns spaces and
tabs in addition to newlines.
---
lib/base64.c| 24 +---
tests/test-base64.c |4 ++--
2 fi
Hello,
Currently in gnutls we used gnulib for the main library (LGPLv3) and
the applications (GPLv3). In the main library we use only modules that
are lgpl and the applications use few gpl modules as well. However it is
not easy to make sure that only LGPL modules of gnulib are used in the
library
Hi,
I got the attached bug report. Is there any information we can provide
to solve that issue? The gl/ directory in the latest gnutls can be seen at:
http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=tree;f=gl;h=0e924fda61b6f797dea7f61dec6006732ae87140;hb=6638c0567889ffa3a89ee82335d0abc05e44838c
On 11/07/2011 10:52 PM, Bruno Haible wrote:
> [CCing Ludovic. The thread starts at
> <https://lists.gnu.org/archive/html/bug-gnulib/2011-11/msg00079.html>]
> Nikos Mavrogiannopoulos wrote:
>> Wouldn't it be better to add an option to enable
>> it only in systems wh
Hello,
After adding few modules to gnulib the gnutls-guile library had few
failures in testsuite in some arm and mips systems. After some
investigation[0] it seems that the issue was that the new gnulib modules
were depending on largefile module which defines a 64-bit off_t even on
32-bit systems.
On 09/25/2011 07:29 PM, Bruno Haible wrote:
Hi Nikos,
I got some bug report [0] on gnutls that on MacOSX gnutls compilation
fails with the following error.
serv.c:1236: warning: cast to pointer from integer of different size
In file included from ./../gl/unistd.h:112,
from ./../gl/stdlib.h:
Hello,
I got some bug report [0] on gnutls that on MacOSX gnutls compilation
fails with the following error.
serv.c:1236: warning: cast to pointer from integer of different size
In file included from ./../gl/unistd.h:112,
from ./../gl/stdlib.h:90,
from udp-serv.c:5:
./../gl/getopt.h:197: error
On 04/12/2011 03:50 PM, Simon Josefsson wrote:
>>> I'm surprised the gnulib memxor ends up being used by GnuTLS at all.
>>> Nikos, shouldn't the Nettle implementation be used instead? Is this a
>>> question of the GnuTLS (gnulib) memxor symbol replacing the memxor that
>>> is shipped with Nettle?
On 04/12/2011 03:12 PM, Simon Josefsson wrote:
>>> I had 10% speed-ups in a web server that used gnutls with the optimized
>>> version of memxor. That is because CBC encryption mode uses XOR heavily.
>>> 10% is enormous speed-up considering that this is a very small part of
>>> the encryption proc
On 04/12/2011 02:29 AM, Bruno Haible wrote:
>> As an unrelated suggestion for memxor.c I had a discussion with
>> another project about that and we concluded on a gmp-based version
>> that is orders of magnitude faster. It would be nice if gnulib
>> included the optimized code by default.
> If yo
On 04/11/2011 12:56 AM, Paul Eggert wrote:
> On 04/10/2011 03:07 PM, Nikos Mavrogiannopoulos wrote:
>> As I understand it AC_C_RESTRICT checks whether restrict
>> is supported by the C compiler. I'm using the C++ compiler.
>
> In that case, AC_C_RESTRICT should repor
On 04/10/2011 11:54 PM, Paul Eggert wrote:
> On 04/10/2011 12:53 AM, Nikos Mavrogiannopoulos wrote:
>> Attached is a patch that fixes the time.h compilation under C++.
>
> This shouldn't be needed, since gl_HEADER_TIME_H requires
> gl_HEADER_TIME_H_BODY, which requires AC
Attached is a patch that fixes the time.h compilation under C++.
regards,
Nikos
>From 6bdd56fbd4ecad4b00d3bbd76dd343a52622a876 Mon Sep 17 00:00:00 2001
From: Nikos Mavrogiannopoulos
Date: Sun, 10 Apr 2011 09:51:58 +0200
Subject: [PATCH] Fix compilation issue under C++ due to restrict C qualif
46 matches
Mail list logo
