Compiling on FreeBSD 12 gives a warning per use of c_ macros, for example
http_parse.c:187:10: warning: 'c_isblank' was marked unused but was used
[-Wused-but-marked-unused]
while (c_isblank(*s)) s++;
This is true also for c_isdigit, c_isspace, etc.
Is that expected behavior and
Hi Bruno,
On 8/28/19 4:09 PM, Bruno Haible wrote:
> Hi Tim,
>
>> Compiling on FreeBSD 12 gives a warning per use of c_ macros, for example
>>
>> http_parse.c:187:10: warning: 'c_isblank' was marked unused but was used
>> [-Wused-but-marked-unused]
>> while (c_isblank(*s)) s++;
>>
Hi Bruno,
On 28.08.19 17:28, Bruno Haible wrote:
>> The option -Wused-but-marked-unused is indirectly activated by
>> -Weverything
>
> -Weverything is not something we can support in gnulib. For the
> meaning of this option, see
> https://quuxplusone.github.io/blog/2018/12/06/dont-use-weverything
Hi,
we just had an issue with the bootstrap script because wget -q
suppresses error output.
E.g. instead of
"
ERROR: cannot verify translationproject.org's certificate, issued by
'CN=Let\'s Encrypt Authority X3,O=Let\'s Encrypt,C=US':
Unable to locally verify the issuer's authority.
"
there is
Thank you, Paul !
On 06.10.19 06:38, Paul Eggert wrote:
> On 10/4/19 8:34 AM, Tim Rühsen wrote:
>> Instead of -q we could use -nv to avoid disguising the real error.
>> But there will be some diagnostic noice...
>
> At this point the bootstrap script is so noisy that a
From 3bde5ad266986687ad38a8742244099970ed7cc7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tim=20R=C3=BChsen?=
Date: Sun, 6 Oct 2019 16:52:23 +0200
Subject: [PATCH] users.txt: Fix URL for libidn2
---
users.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/users.txt b/users.txt
Hi Bernhard,
it's already in gnulib since yesterday. I didn't expect you to come up
with a patch, else I would have informed you on the bug tracker.
Please excuse my lack of communication here.
Regards, Tim
On 10/7/19 11:13 AM, Bernhard M. Wiedemann wrote:
> e.g. when running in a build environ
Hi Christian,
I can even reproduce on Debian unstable:
./bootstrap
./configure
make
cd doc
make dvi
Regards, Tim
On 10/17/19 3:11 PM, Christian Grothoff wrote:
> I downloaded an Ubuntu 18.04.3 LTS VM image, installed the required
> packages (including texlive 2017 and texinfo 6.5) and it _still
@enumerate a
173:@end enumerate
314:@end enumerate
As you can see L67-L314 is an enumerate, where L286 (@heading) is enclosed.
So it looks like a problem in gpl-2.0.texi (or in the texi2dvi command
chain). Any ideas ?
Regards, Tim
On 10/18/19 9:54 AM, Tim Rühsen wrote:
> Hi Christian,
&g
There was a stale 'doc/texinfo.tex' here (no idea where it's from).
After removing it, everything works out smooth. Sorry for the wind.
Regards, Tim
On 10/18/19 10:02 AM, Tim Rühsen wrote:
> @Paul
>
> The error says
> "/home/oms/src/libmicrohttpd/doc/gpl-2.0.tex
On 11/28/19 11:11 PM, Bruno Haible wrote:
> Hi Dagobert,
>
> lib/gnulib.mk there is a suspicious addition to libgnu_la_LDFLAGS without
> space:
>>
>> libgnu_la_LDFLAGS += $(GETADDRINFO_LIB)$(LTLIBINTL)
>> ...
>> libgnu_la_LDFLAGS += $(LTLIBICONV)
>> libgnu_la_LDFLAGS += $(LTLIBINTL)
>> libgnu_la
On 11/28/19 11:11 PM, Bruno Haible wrote:
> Hi Dagobert,
>
> lib/gnulib.mk there is a suspicious addition to libgnu_la_LDFLAGS without
> space:
>>
>> libgnu_la_LDFLAGS += $(GETADDRINFO_LIB)$(LTLIBINTL)
>> ...
>> libgnu_la_LDFLAGS += $(LTLIBICONV)
>> libgnu_la_LDFLAGS += $(LTLIBINTL)
>> libgnu_la
Hi Bruno,
On 30.11.19 13:06, Bruno Haible wrote:
>> Please review the patch - surely some of my python constructs could be
>> done more elegant.
>
> Review:
> - GLModuleSystem.getLink: Looks good. This method corresponds to
> func_get_link_directive and therefore should not do any joining or so
Hi Bruno,
On 30.11.19 15:15, Bruno Haible wrote:
>> There is one LF at the end of the diff file (taken from the email I
>> received via mailing list, also cross-checked with bug-gnulib archive).
>
> Indeed, the one in bug-gnulib archive and even the one I get by using
> the web access to my IMAP
Hi Dago,
On 30.11.19 18:33, Dagobert Michelsen wrote:
> Am 30.11.2019 um 16:28 schrieb Tim Rühsen :
>> On 30.11.19 15:15, Bruno Haible wrote:
>>>> There is one LF at the end of the diff file (taken from the email I
>>>> received via mailing list, also cros
On 12/5/19 4:12 PM, Wes Hurd wrote:
> Hi,
>
> It seems GNUlib quote encoding goes to Unicode smart quotes, which causes
> command-line program output to be in smart quotes.
> Smart quotes are dangerous for programmers and technical users, and should
> be avoided in program output.
>
> Originally
Hi Bruno, hi gnulib developers,
it's a joy to follow the posts on this list - you (all) surprise,
impress and inspire me with your code but even more with your detailed
explanations / documentations.
Thank you so much for your ongoing work !!!
[E.g. this post made me check my code for mbtowc/mbr
Hi Bruno,
On 28.12.19 12:17, Bruno Haible wrote:
> Would you find it useful to have an immutable string type in gnulib?
The idea is good in fact had similar thoughts/needs a while ago. IMO,
the use cases are mostly in the testing area (especially fuzzing).
As a more general approach, a function
On 29.12.19 10:45, Bruno Haible wrote:
> Tim Rühsen wrote:
>> the use cases are mostly in the testing area (especially fuzzing).
>
> Indeed. During fuzzing, you want to check against any kind of buggy/undefined
> behaviour, and writing into arbitrary memory is one of these kinds
On 29.12.19 19:49, Paul Eggert wrote:
> On 12/29/19 4:07 AM, Tim Rühsen wrote:
>> Introducing a stronger 'const' could be helpful in some situations
>
> D has 'immutable' for that. It doesn't work as well as one might think.
It all depends on the implem
On 27.12.19 11:51, Bruno Haible wrote:
> Aga wrote:
>> I do not know if
>> you can (or if it is possible, how it can be done), extract with a way a
>> specific
>> a functionality from gnulib, with the absolute necessary code and only that.
>
> gnulib-tool does this. With its --avoid option, the d
On 12/31/19 10:53 AM, Bruno Haible wrote:
> Hi Tim,
>
>>> - providing primitives for string allocation reduces the amount of buffer
>>> overflow bugs that otherwise occur in this area. [1]
>>> [1] https://lists.gnu.org/archive/html/bug-gnulib/2019-09/msg00031.html
>
>> here is a string co
Hi Bruno,
On 1/6/20 1:46 PM, Bruno Haible wrote:
> - providing primitives for string allocation reduces the amount of
> buffer
> overflow bugs that otherwise occur in this area. [1]
> [1] https://lists.gnu.org/archive/html/bug-gnulib/2019-09/msg00031.html
>>> ...
>> We creat
On 1/6/20 5:08 PM, Tim Rühsen wrote:
>> * What about reusing the complete vasnprintf.c for (B), rather than
>> adding another, limited printf-like implementation?
>
> Yes, would be nice. At least for appending we need an extra
> malloc/malloc/memcpy/free.
>
Hi,
with the latest gnulib (a7903da07d3d18c23314aa0815adbb4058fd7cec) on
Debian Stretch:
In file included from /usr/include/string.h:630:0,
from ./string.h:41,
from strndup.c:21:
strndup.c:26:1: error: expected identifier or '(' before '__extension__'
strndup (c
Hi,
with the latest gnulib (a7903da07d3d18c23314aa0815adbb4058fd7cec) on
FreeBSD 11.2-RELEASE-p4 (with clang 6.0):
CCLD wget2
/usr/bin/ld: undefined reference to symbol
`pthread_mutexattr_gettype@@FBSD_1.0' (try adding -lthr)
//lib/libthr.so.3: could not read symbols: Bad value
clang: error
On 1/7/20 3:24 PM, Tim Rühsen wrote:
> Hi,
>
> with the latest gnulib (a7903da07d3d18c23314aa0815adbb4058fd7cec) on
> Debian Stretch:
>
> In file included from /usr/include/string.h:630:0,
> from ./string.h:41,
> from strndup.c:21:
Hi Bruno,
On 07.01.20 19:00, Bruno Haible wrote:
>> with the latest gnulib (a7903da07d3d18c23314aa0815adbb4058fd7cec) on
>> Debian Stretch:
>>
>> In file included from /usr/include/string.h:630:0,
>> from ./string.h:41,
>> from strndup.c:21:
>> strndup.c:26:1: err
FYI, the issue below also happens with --disable-threads.
Using --enable-threads=isoc fixes it (found in an earlier post on this ML).
Regards, Tim
On 1/7/20 4:03 PM, Tim Rühsen wrote:
> Hi,
>
> with the latest gnulib (a7903da07d3d18c23314aa0815adbb4058fd7cec) on
> FreeBSD 11.2-RELE
Hi José,
you could look at libidn2 as an example how to use system libunistring
if there (or if new enough) and fallback to gnulib unistring.
(BTW, libunistring is made of the gnulib unistring modules)
It creates a separate dir / library for gnulib unistring functions,
*BUT* only uses it when a s
Hi Bruno,
On 1/13/20 12:01 PM, Bruno Haible wrote:
> Hi Tim,
>
>> you could look at libidn2 as an example how to use system libunistring
>> if there (or if new enough) and fallback to gnulib unistring.
>> (BTW, libunistring is made of the gnulib unistring modules)
>>
>> It creates a separate dir
cc
==1671628==ABORTING
Maybe someone who knows glob better than me could have a look. It seems
to be a regression.
Regards, Tim
/*
* Created 17.01.2019 by Tim Rühsen
*
* Call glob() using data from fuzzer crash file
*
* Build and execute with instrumented gnulib (amend -I paths as needed)
after dirname is freed, the code still accesses end_name.
>
> Can you please test this patch?
>
> Thank you very much for this report! I expect that the fix will also need
> to go into glibc.
>
>
> 2020-01-17 Bruno Haible
>
> glob: Fix use-after-free bug.
Hi Bruno,
thanks for your work !
I can confirm that your patch fixes the issue here.
On 1/20/20 4:01 AM, Bruno Haible wrote:
>>> FreeBSD 11.2-RELEASE-p4 (with clang 6.0):
>>>
>>> CCLD wget2
>
> Please make it a habit to use "make V=1" when submitting a report.
> I don't want to see "CCLD
Not sure if the compiler is correct here, but maybe worth a look:
hash.c:549:11: error: implicit conversion from 'unsigned long' to
'float' changes value from 18446744073709551615 to 18446744073709551616
[-Werror,-Wimplicit-int-float-conversion]
if (SIZE_MAX <= new_candidate)
^
On 1/20/20 7:04 PM, Bruno Haible wrote:
> CCLD wget2
>>>
>>> Please make it a habit to use "make V=1" when submitting a report.
>>> I don't want to see "CCLD wget2"; I want to see the actual link
>>> command line.
>>
>> I don't have direct console/shell access - the issue is/was on a Free
Hi Bruno,
On 1/27/20 2:09 PM, Bruno Haible wrote:
>> Not sure if the compiler is correct here, but maybe worth a look:
>>
>> hash.c:549:11: error: implicit conversion from 'unsigned long' to
>> 'float' changes value from 18446744073709551615 to 18446744073709551616
>> [-Werror,-Wimplicit-int-float
On 09.02.20 15:44, Mats Erik Andersson wrote:
> Hello there!
>
> This note has its origin in a report received at bug-inetutils.
> The following test code for snprintf() is a simplyfied detection
> I have implemented as a warning-only test in Gnu Inetutils.
> My point is that Linux/glibc and kfree
On 2/10/20 4:02 AM, Bruno Haible wrote:
> Tim Rühsen wrote:
>> gcc -Wall tells you so (gcc 8 and upwards):
>> $ gcc -Wall msg.c -o msg
>> msg.c: In function ‘main’:
>> msg.c:11:13: warning: passing argument 1 to restrict-qualified parameter
>> aliases with
On 2/17/20 4:53 AM, Bruno Haible wrote:
> Paul Eggert wrote:
>> if GCC generated warnings for that sort of thing, the warnings would be false
>> alarms.
>
> Yes, and this in turn means that the ability to produce useful warnings via
> 'restrict' is limited. In this example:
> =
There seems to be a prototype missing in uninorm/decompose-internal.h:
uninorm/decompose-internal.c:26:27: warning: no previous prototype for
'gl_uninorm_decompose_merge_sort_fromto' [-Wmissing-prototypes]
26 | #define merge_sort_fromto gl_uninorm_decompose_merge_sort_fromto
|
Hi,
dosname.h (included by dirname.h) and filename.h overlap in macro
definition. This currently results in an error here:
In file included from wget.c:61:
In file included from ../lib/dirname.h:24:
../lib/dosname.h:36:10: error: 'FILE_SYSTEM_PREFIX_LEN' macro redefined
[-Werror,-Wmacro-redefined
Is this EPERM intended ? If yes, there should be a comment.
lib/unlink.c (rpl_unlink):
/* Trailing NUL will overwrite the trailing slash. */
char *short_name = malloc (len);
if (!short_name)
{
errno = EPERM;
return -1;
On 26.03.20 00:46, Bruno Haible wrote:
> Jeffrey Walton wrote:
>> CI tests should be catching these mistakes. (And problems like
>> _NoReturn on OS X).
>
> Yes, CI can catch some mistakes. Like, just last week, this one: [1].
>
> Tim and I maintain a continuous integration for gnulib at [2].
>
Hi Bruno,
thank you so much for reorganizing the code.
I updated both, Wget and Wget2, to the latest gnulib and it looks good
for me :-)
Regards, Tim
On 3/28/20 2:07 PM, Bruno Haible wrote:
Hi Tim,
dosname.h (included by dirname.h) and filename.h overlap in macro
definition. This currently
On 05.05.20 03:14, Bruno Haible wrote:
> Paul Eggert wrote:
>>> We could switch the order such that Wget is the default and rsync is used
>>> as a
>>> fallback
>>
>> That sounds better than reverting, no? Perhaps you could propose a patch.
>
> No. From the point of security, "wget as default and
On 06.05.20 18:37, Bruno Haible wrote:
>> We could also check for an existing wget in bootstrap.conf and set
>> SKIP_PO=1 if not found. While it 'just works' it also disguises the real
>> problem and the user might get something unexpected
>> (non-internationalized wget).
>
> Alternatively, you co
Hi,
i would like to ask for your expert knowledge.
How to prevent file descriptor leaks in a multi-threaded application
that fork+exec. Quick answer is surely "use O_CLOEXEC" to close those
file descriptors on exec.
But how does this work with fopen in a portable way ?
GNU libc has the 'e' flag
Hi Bruno,
On 11.05.20 18:37, Bruno Haible wrote:
> Hi Tim,
>
>> i would like to ask for your expert knowledge.
>>
>> How to prevent file descriptor leaks in a multi-threaded application
>> that fork+exec. Quick answer is surely "use O_CLOEXEC" to close those
>> file descriptors on exec.
>>
>> But
On 16.05.20 17:33, Jeffrey Walton wrote:
> On Sat, May 16, 2020 at 10:05 AM Bruno Haible wrote:
>> 3) The QA automation perspective
>>
>>
>> For QA automation, a multitude of program executions are done with a
>> memory leak checker enabled. Since it needs to be au
Hi,
thanks for your excellent write-up, Bruno.
Just want to add my thoughts :)
When talking about finding memory leaks, like in your wiki page, you
should also mention static analyzers and their ability to find memory
leaks (clang static analyzer, gcc-10 -fanalyzer, Coverity, cppcheck, ...).
Th
,3 +1,7 @@
+2020-05-18 Tim Rühsen
+
+ * m4/getdelim.m4: Fix memleak.
+
2020-05-17 Bruno Haible
Clarify intended usage of the license file modules.
diff --git a/m4/getdelim.m4 b/m4/getdelim.m4
index 9f4c7f6e9..ac3917b11 100644
--- a/m4/getdelim.m4
+++ b/m4/getdelim.m4
@@ -1,4 +1,4 @@
-# getd
Hi Bruno,
On 18.05.20 13:50, Bruno Haible wrote:
> Hi Tim,
>
>> With leak sanitizer on, the test for getdelim fails due to a memory leak.
>
> Is this the only configure test that fails this way?
The only one that fails when running GNU Poke ./configure.
> I mean, it's 3 years since we last loo
On 19.05.20 18:11, Marc Nieper-Wißkirchen wrote:
> Am Di., 19. Mai 2020 um 17:51 Uhr schrieb Paul Eggert :
>>
>> On 5/19/20 8:35 AM, Marc Nieper-Wißkirchen wrote:
It is, however, locale-dependent, and there is no "c_dtoastr"
version as there is a "c_strtod". (Could we get such a wrapper?)
On 19.05.20 21:10, Marc Nieper-Wißkirchen wrote:
> Am Di., 19. Mai 2020 um 19:23 Uhr schrieb Tim Rühsen :
>
>> "copyright" here means more "Nutzungsrecht" which you can transfer also
>> in Germany. You still stay the "Urheber".
>
> If transfe
On 18.05.20 21:44, Bruno Haible wrote:
> Hi Tim,
>
>>> The way to determine the answer is:
>>> 1. Create a test dir of all gnulib modules.
>>> 2. Configure it with --config-cache.
>>> 3. Configure it with --config-cache and your sanitizer options.
>>> 4. Compare the generated config.cache and co
Hi Bruno,
On 20.05.20 00:46, Bruno Haible wrote:
> Hi Tim,
>
>>> rm -rf ../testdir-all; ./gnulib-tool --create-testdir
>>> --dir=../testdir-all --single-configure
>>
>> This results in:
>>
>> executing autopoint --force
>> autopoint: *** The AM_GNU_GETTEXT_VERSION declaration in your configure
Hi Bruno,
On 18.05.20 21:44, Bruno Haible wrote:
> Hi Tim,
>
>>> The way to determine the answer is:
>>> 1. Create a test dir of all gnulib modules.
>>> 2. Configure it with --config-cache.
>>> 3. Configure it with --config-cache and your sanitizer options.
>>> 4. Compare the generated config.cac
Hi Bruno,
On 21.05.20 21:31, Bruno Haible wrote:
> Hi Tim,
>
> These comparisons are not so useful, because they not only come from different
> compilers (gcc vs. clang) but also from systems with different libcs: there
> are differences regarding libm, calloc, thrd_create, pthread_sigmask, and
On 23.05.20 18:08, Paul Eggert wrote:
> On 5/23/20 8:56 AM, Pádraig Brady wrote:
>> Note -Wanalyzer... flags are ineffective without -fanalyzer.
>> Also -Wanalyzer-too-complex (now auto enabled by gnulib) is currently quite
>> problematic with -fanalyzer.
>
> Hmm, that's odd, since I recall gettin
Hi Bruno,
On 23.05.20 22:47, Bruno Haible wrote:
> Tim Rühsen wrote:
>> - clang-10 with unset CFLAGS (*.clang-10)
>>
>> And the same set with -fsanitize... (*.sanitize).
>
> The other differences between the configure results without and with
> sanitizers
>
Hi Ed,
On 11.06.20 21:23, Ed Maste wrote:
> On Thu, 26 Mar 2020 at 05:51, Tim Rühsen wrote:
>>
>> We just need a mirror / fork on Github that we push to (sync) from time
>> to time. If someone cares for the initial Travis and/or Cirrus setup
>> with OSX / FreeBSD / Win
Hey,
after updating gnulib, I see this on all CI pipelines (Debian, Fedora,
Alpine, Arch, ...):
In file included from /usr/include/x86_64-linux-gnu/sys/param.h:28,
from ./minmax.h:34,
from md2.c:30:
./signal.h:682:13: error: size of array 'verify_NSIG_constraint'
On 02.08.20 15:41, Bruno Haible wrote:
> Tim Rühsen wrote:
>> The surrounding code in lib/signal.h is
>> #if 1
>> # if !0
>
> Huh? HAVE_POSIX_SIGNALBLOCKING evaluates to 0 ?!
>
> There was a change to m4/signalblocking.m4 recently, but for me it works.
> Can
On 23.01.21 07:09, Ryan Schmidt wrote:
On Jan 22, 2021, at 16:47, Tim Rühsen wrote:
On 21.01.21 01:34, Ryan Schmidt wrote:
Hi, I'm the maintainer of wget in MacPorts.
In the version of clang included with Xcode 12 and later, implicit declaration
of functions is an error.
During conf
Hi,
I just updated gnulib to commit 2671376bc and have build issues on
Alpine (using docker; FROM alpine:latest).
Not saying this commit is faulty, I didn't update gnulib since April 2021.
Some generated header files look like
bash-5.1# head -3 lib/uniwidth.h
/* DO NOT EDIT! GENERATED AUTOMAT
On 03.01.22 00:38, Bruno Haible wrote:
Paul Eggert wrote:
I'd like to try the approach a bit more (especially as this prompted me
to simplify it a bit :-). So I installed the first attached patch to
Gnulib, to work around the bug in BusyBox 'sed'.
Thanks. I confirm that it works on Alpine Linu
Hi all,
On 14.06.22 00:39, Paul Eggert wrote:
In many Gnu projects, the 'configure' script is the biggest barrier to
building because it takes s long to run. Is there some way that we
could improve its performance without completely reengineering it, by
improving Bash so that it can parall
Hi,
I am at switching wget2 multithreading from C99+glthreads to C11
(threads.h).
The tests work well on Linux (amd64) (Debian unstable/testing/stable,
Fedora 35, Arch, Alpine/muslc) with native builds (gcc or clang).
But they completely fail when cross-building with MinGW64 (on Debian
boo
Hi Bruno,
On 05.08.22 20:27, Bruno Haible wrote:
Hi Tim,
I am at switching wget2 multithreading from C99+glthreads to C11
(threads.h).
I hope that you have considered the Gnulib documentation on this topic:
https://www.gnu.org/software/gnulib/manual/html_node/Choosing-a-multithreading-API.ht
On 06.08.22 19:40, Bruno Haible wrote:
Tim Rühsen wrote:
I read that even the MS C compilers / libraries support ISO C thread
nowadays,
I can't confirm this. If it were true, they would have documentation for it.
But a web search for "mtx_lock site:microsoft.com" returns no me
Hi,
I just git cloned gnulib to work on certain bugs.
Not sure how to build and run the test suite. The README just points me
to a .texi file which is hardly readable, at least I get a headache
after ~10s.
doc/README... something about web pages.
I tried 'make' - nothing happened.
'make che
Bruno ! You saved my day !
I put your description with some small amendments into the README.
Here's the patch.
With Best Regards, Tim
On 05/16/2017 03:17 PM, Bruno Haible wrote:
> Hi Tim,
>
>> Not sure how to build and run the test suite. The README just points me
>> to a .texi file which
Oh, just realized that ChangeLog has to be manually edited.
Here is the amended patch.
With Best Regards, Tim
On 05/16/2017 03:52 PM, Tim Rühsen wrote:
> Bruno ! You saved my day !
>
>
> I put your description with some small amendments into the README.
> Here's the
Fixing a small resource leak.
With Best Regards, Tim
From d52c2951f4d805042a9dcb4cc9de0a4cabe1999d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tim=20R=C3=BChsen?=
Date: Wed, 17 May 2017 09:22:46 +0200
Subject: [PATCH] parse-datetime: Fix memleak
* lib/parse-datetime.y (parse_datetime2): Cleanup o
Hi Bruno,
On 05/17/2017 10:15 AM, Bruno Haible wrote:
> Hi Tim,
>
> + Contributor's Quick Start Guide
>
> This does not belong in the README. The README is for first-time *users*.
> For first-time *contributors*, many GNU packages have a HACKING file,
> but gnulib already has a doc sect
Hi,
'make coverage' fails here due to two tests failing, thus no coverage
report is created.
Here is a patch to fix this by skipping those tests.
I couldn't find a better solution.
There still is
Processing file gllib/gllib/unicase/special-casing-table.gperf
genhtml: ERROR: cannot read
/usr/o
Hi,
just a couple of questions...
How do I enable valgrind testing ?
What about automated / CI testing ?
We (the Wget maintainers) recently set up a group 'gnuwget' on Gitlab
with CI runners (Debian, CentOS, Fedora). I could add gnulib as a
project so that it can use these runners as well. The o
On Mittwoch, 17. Mai 2017 19:09:52 CEST Bruno Haible wrote:
> Hi Tim,
>
> > What about automated / CI testing ?
> > We (the Wget maintainers) recently set up a group 'gnuwget' on Gitlab
> > with CI runners (Debian, CentOS, Fedora). I could add gnulib as a
> > project so that it can use these runne
On Mittwoch, 17. Mai 2017 19:09:05 CEST Bruno Haible wrote:
> Hi Tim,
>
> > How do I enable valgrind testing ?
>
> There is this doc [1] and this recent mail thread [2].
Ok, there seems to a misunderstanding. While I have no problems to setup/run
most projects to use valgrind, I have problems t
On Mittwoch, 17. Mai 2017 19:10:40 CEST Bruno Haible wrote:
> Hi Tim,
>
> > What about fuzzing ?
> > I just work on OSS-Fuzz[1] integration for Wget2. Is There interest in a
> > 'starter' for gnulib with a example fuzz code ?
>
> Gnulib by itself does not provide functionality that consumes input
bineb3WvVyDgw.bin
Description: PGP/MIME version identification
encrypted.asc
Description: OpenPGP encrypted message
binISaaHroFt0.bin
Description: PGP/MIME version identification
encrypted.asc
Description: OpenPGP encrypted message
On 05/17/2017 06:40 PM, Bruno Haible wrote:
> Hi Tim,
>
>> 'make coverage' fails here due to two tests failing, thus no coverage
>> report is created.
>> I couldn't find a better solution.
>
> In the comment, you write "possible crash when compiled with -coverage".
> Our tests should not crash, w
On 05/18/2017 01:00 PM, Bruno Haible wrote:
> Hi Tim,
>
>> Processing file gllib/gllib/unicase/special-casing-table.gperf
>> genhtml: ERROR: cannot read
>> /usr/oms/src/testdir1/gllib/gllib/unicase/special-casing-table.gperf
>> maint.mk:1500: recipe for target 'gen-coverage' failed
>>
>> (Maybe th
On 05/17/2017 09:43 PM, Assaf Gordon wrote:
> Hello,
>
> On Wed, May 17, 2017 at 09:20:33PM +0200, Tim Rühsen wrote:
>> On Mittwoch, 17. Mai 2017 19:09:52 CEST Bruno Haible wrote:
>>>
>>> > What about automated / CI testing ?
>
>>> [...] Therefo
Hi,
are there know issues with select() when build for MinGW ?
Code is basically:
FD_ZERO(&fdset);
FD_SET(fd, &fdset);
rd = &fdset;
wr = &fdset;
select (fd + 1, rd, wr, NULL, NULL);
Select() always immediately comes back with 0, WSAGetLastError() return
6 (WSA_INVALID_HANDLE). fd is a valid
On Donnerstag, 18. Mai 2017 19:29:18 CEST Bruno Haible wrote:
> Tim Rühsen wrote:
> > $ ./gnulib-tool --create-testdir --dir=../testdir1
> > $ cd ../testdir
> > $ ./configure CFLAGS="-g -coverage"
> > $ make clean && make coverage
>
> I did
>
On 05/18/2017 10:15 PM, Bruno Haible wrote:
> Hi Tim,
>
>>> What do you get if you change the value 500 in
>>> tests/test-fprintf-posix2.c to a larger or smaller value?
>>
>> Both succeed with 5000 (10x higher).
>
> Good, that's the way I'd like to see it fixed. But a malloc(50 MB)
> is e
On 05/18/2017 07:15 PM, Bruno Haible wrote:
>> Currently discussed here:
>> https://gitlab.com/gnuwget/wget2/issues/212
>
> Note that 'wine' is *not* a supported platform for gnulib.
>
> It is already time consuming enough to try to support mingw and MSVC.
> Supporting 'wine' would mean to additi
Hi,
on GNU/Linux open() on a directory returns -1 and sets errno to EISDIR.
Built on MinGW / Win32 the same open sets errno to EACCES.
We currently use a work-around like
+ int rc = open(pathname, flags, mode);
+#ifdef _WIN32
+ if (rc < 0 && errno == EACCES) {
+ DWORD
On 05/22/2017 12:58 PM, Tim Rühsen wrote:
> Hi,
>
> on GNU/Linux open() on a directory returns -1 and sets errno to EISDIR.
>
> Built on MinGW / Win32 the same open sets errno to EACCES.
>
>
> We currently use a work-around like
> + int rc = open(pathname, fla
On 05/22/2017 02:04 PM, Gisle Vanem wrote:
> Tim Rühsen wrote:
>
>> Built on MinGW / Win32 the same open sets errno to EACCES.
>>
>>
>> We currently use a work-around like
>> +int rc = open(pathname, flags, mode);
>> +#ifdef _WIN32
>> +if
On Montag, 22. Mai 2017 08:00:14 CEST Paul Eggert wrote:
> On 05/22/2017 03:58 AM, Tim Rühsen wrote:
> > on GNU/Linux open() on a directory returns -1 and sets errno to EISDIR.
>
> No, for example on my platform (Fedora 25 x86-64), 'strace cat .'
> outputs the l
On 05/22/2017 10:38 PM, Bruno Haible wrote:
> Tim Rühsen wrote:
>>>> on GNU/Linux open() on a directory returns -1 and sets errno to EISDIR.
>>>
>>> No, for example on my platform (Fedora 25 x86-64), 'strace cat .'
>>> outputs the line 'ope
ncept. You might prefer a different approach.
Regards, Tim
From 0b7efcb91485a808edd4a39c58d6dfe267b4097b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tim Rühsen?=
Date: Sat, 1 Jul 2017 20:35:55 +0200
Subject: [PATCH] Fix memleak in glob()
---
lib/glob.c | 31 +--
1 file chan
Hi Bruno,
On Sonntag, 2. Juli 2017 02:34:17 CEST Bruno Haible wrote:
> Hi Tim,
>
> > Attached is a patch fixing the issue for me
>
> The 'return 0;' in line 1104 is correct, because 'dirname' is stuffed into
> the result array in the lines before. Therefore dirname must NOT be freed
> here.
Thi
Hi Bruno,
On Sonntag, 2. Juli 2017 14:00:27 CEST Bruno Haible wrote:
> > In code that I am responsible for,
> > especially complex code as glob(), I also set pointers to NULL after
> > free() or when assigning/moving to another variable.
>
> Such a coding style does not help. What you need is to
On 07/03/2017 01:22 AM, Paul Eggert wrote:
> On 07/01/2017 01:44 PM, Tim Rühsen wrote:
>> Hi,
>>
>> fuzzing glob.c immediately discovered a leak.
>>
>> At ~L600 in glob.c, 'dirname' is heap allocated.
>> It is free'd at label 'out
2 AM, Paul Eggert wrote:
> On 07/01/2017 01:44 PM, Tim Rühsen wrote:
>> Hi,
>>
>> fuzzing glob.c immediately discovered a leak.
>>
>> At ~L600 in glob.c, 'dirname' is heap allocated.
>> It is free'd at label 'out', but some code paths dire
1 - 100 of 260 matches
Mail list logo
