Re: bug#49308: GNU sed for Tru6 configure CFLAGS?

(adding gnulib@) Hello, On 2021-07-01 12:35 a.m., Jay K wrote: Hi. I built GNU sed for Tru64. With native cc, not gcc. I realize it is an old system. $ uname -srm OSF1 V5.1 alpha $ which cc /usr/bin/cc $ cc -V Compaq C V6.5-303 (dtk) on HP Tru64 UNIX V5.1B (Rev. 2650) Compiler Driver

users.txt: add datamash, time

Hello, I propose the following small addition to users.txt . -assaf >From b3bf948d4179ef144a87568ecd282e960f6bf293 Mon Sep 17 00:00:00 2001 From: Assaf Gordon Date: Sun, 23 Feb 2020 23:07:42 -0700 Subject: [PATCH] users.txt: Add datamash, time * users.txt: Add datamash, time. --- Change

Re: bug#39652: SED preinstall check failed

tag 39652 moreinfo stop (added bug-gnulib@) Hello, On 2020-02-17 8:12 p.m., Gopinath Sekar via wrote: FAIL: test-rename [...] See gnulib-tests/test-suite.log Please report to bug-...@gnu.org

Re: git-version-gen: allow 'snapshot' as .tarball-version contents

Hello Bruno, On 2019-10-13 3:18 p.m., Bruno Haible wrote: Dmitry V. Levin wrote: I need a non-numeric version for continuous publishing of gettext snapshot tarballs, and I want the tarballs to be called gettext-snapshot.tar.gz, I wonder how users of these tarballs would be able to identify

gnupload with gpg>=v2.1 fails due to missing TTY

Hello, While uploading a new archive to ftp.gnu.org, I noticed that gnupload does not play nice with newer version of gpg. On Debian 10 with /usr/bin/gpg being "gpg (GnuPG) 2.2.12", the signage step fails with: $ ./build-aux/gnupload --to ftp.gnu.org:datamash datamash-1.5.tar.gz Enter GPG

test-symlink fails on "lustre" file system (was: bug#37312: test failure in sed-4.7)

(adding bug-gnulib@) Hello, Thomas Oppe (CC'd) reported the following gnulib test failure on GNU/Linux with "lustre" file system. Details below: === The system details are: 1. Is this reproducible? After running "make check", there should be an executable file called

Re: iconv_open: non-gnu make fails to generate "iconv_open-aix.h"

WOW! Bruno, that was exactly the issue! I should've asked you directly before spending hours debugging and bisecting :) On 2019-08-24 3:36 p.m., Bruno Haible wrote: The fact that the error message in both case is "don't know how to make " perhaps hints there's some common dependency

Re: iconv_open: non-gnu make fails to generate "iconv_open-aix.h"

On 2019-08-24 3:08 p.m., Bruno Haible wrote: Assaf Gordon wrote: this version of "make" is the native version (=preinstalled by the operating system) in FreeBSD and NetBSD So, by improving the support for OpenBSD I regressed on the same feature in FreeBSD? Ouch. Somewhat related,

Re: iconv_open: non-gnu make fails to generate "iconv_open-aix.h"

Hello Bruno, On 2019-08-24 2:19 a.m., Bruno Haible wrote: Perhaps this is a non-issue, and only gnu-make is supported for this bootstrapping stage (and non-gnu makes are only supported after "make dist"). Still, worth reporting. Indeed, we need to distinguish the two uses: Building from a

: gettext-and-autopoint documentation update?

Hello, The gnulib manual says: "2. After running gettextize, invoke gnulib-tool and import the gettext module. " https://www.gnu.org/software/gnulib/manual/html_node/gettextize-and-autopoint.html (from 'doc/gnulib-tool.texi' at '@node gettextize and autopoint'). But running:

iconv_open: non-gnu make fails to generate "iconv_open-aix.h"

Hello, While investigating some other issue, I noticed that non-gnu make fails to create 'iconv_open-aix.h' from 'iconv_open-aix.gperf'. Perhaps this is a non-issue, and only gnu-make is supported for this bootstrapping stage (and non-gnu makes are only supported after "make dist"). Still,

Possible GETTEXT version mismatch?

Hello, Just checking, but could it be that there's some mismatch in gnulib about gettext? $ git grep GETTEXT_MACRO_VERSION build-aux/po/Makefile.in.in:GETTEXT_MACRO_VERSION = 0.19 [...] m4/po.m4: AC_SUBST([GETTEXT_MACRO_VERSION], [0.20]) While trying to upgrade gnulib in GNU datamash,

Re: parse-datetime.y - Military Timezones are inverted from the correct sense

gnu date, I suggest the attached patch for coreutils. -assaf >From 19f7eab06af234641a2927514c03570c07a311db Mon Sep 17 00:00:00 2001 From: Assaf Gordon Date: Fri, 9 Aug 2019 19:51:42 -0600 Subject: [PATCH 1/2] gnulib: update to latest --- gnulib | 2 +- 1 file changed, 1 insertion(+), 1 delet

Re: parse-datetime.y - Military Timezones are inverted from the correct sense

Hello, On 2019-08-09 5:31 a.m., Neil Hoggarth wrote: I have observed incorrect handling of "Military" timezones when exercising the --date=... option of the GNU coreutils "date" utility. I believe the underlying problem is with initialization of "military_table[]" in the parse-datetime.y file

Re: Why does close_stdout close stdout and stderr?

I should've added: On 2019-05-07 3:44 a.m., Assaf Gordon wrote: I'm attaching a sample test program to illustrate some points. The program writes to stdout/stderr then optionally calls fclose/fflush/fsync. Note the following: The attached program also calls "ferror" on

Re: Why does close_stdout close stdout and stderr?

fsync failed: Invalid argument This perhaps could be avoided if fsync is checked for errors, then a fall-back to fclose? but that's more code, not less... --- For these reasons, I strongly encourage to keep close_stdout + close_stderr. regards, - assaf /* Test program for gnulib's close_stdout,

Re: selinux: insufficient M4 detection with building static binaries

Hello Bruno, Thanks for investigating further and the clear explanation. On 2019-04-07 5:08 a.m., Bruno Haible wrote: [] So, these are the libraries that are needed. Apparently libselinux is built in such a way that it needs libdl in the shared build, but libsepol in the static build.

Re: [PATCH] ISO 8601 basic format and decimal hours, minutes

Hello Alex, Thank for you putting the time for writing the patch and descriptions in such details. In general: On 2019-02-18 9:00 p.m., Alex Eulenberg wrote: 1. Accept dates in the ISO 8601 basic date and time format. [...]> 2. Accept decimal fractions of time units other than seconds in

selinux: insufficient M4 detection with building static binaries

Hi, While exploring build coreutils as static binary ( https://lists.gnu.org/r/coreutils/2019-04/msg1.html ) I noticed that gnulib's selinux detection is incomplete. Details: The m4/selinux-selinux.m4 files checks for 'setfilecon' function like so: "AC_SEARCH_LIBS([setfilecon], [selinux],

Re: bug#34141: Stackoverflow triggered at lib/regexec.c:1948

(forwarding to gnulib) Hello, Hongxu Chen reported a stack-overflow in regexec. I suspect it is the same as the one reported here: https://lists.gnu.org/r/bug-gnulib/2018-09/msg00066.html But just in case, the full report is below. regards, - assaf On 2019-01-19 10:58 p.m., Hongxu Chen

Re: bug#34142: AddressSanitizer reported heap-buffer-overflow

(forwarding to gnulib) Hello, Hongxu Chen reported a heap-buffer-overflow in gnulib's regexec code. It can be reproduced with current sed using: git clone git://git.sv.gnu.org/sed.git cd sed ./bootstrap && ./configure make build-asan echo 00 |

Re: lib/freadseek.c:69:3: error: #error "Please port gnulib freadseek.c to your platform!

Hello, On 2018-12-29 7:51 a.m., Necktwi Ozfguah wrote: Its coreutils-8.30 with musl-1.1.20 Linux aarch64, Gentoo. I've untared coreutils-8.30.tar.xz cd coreutils-8.30 ./bootstrap ./configure CFLAGS="-march=armv8-a+crc -mtune=cortex-a53 -mcpu=cortex-a53 -ftree-vectorize -O2 -pipe

Re: new module suggestion: fprintftime-check

On 2018-12-28 11:08 p.m., Bruno Haible wrote: [CCing Florian Weimer. Florian, the thread started at https://lists.gnu.org/archive/html/bug-gnulib/2018-12/msg00149.html ] Assaf Gordon wrote: The comment even says: /* Unknown format; output the format, including the '%', since

Re: new module suggestion: fprintftime-check

Hello Bruno, On 2018-12-28 9:34 a.m., Bruno Haible wrote: This function enables syntax-check of the format string. First question: Should this syntax-check be integrated into the nstrftime() and fprintftime() functions? These functions are gnulib inventions, therefore they could be extended

new module suggestion: fprintftime-check

Hello, I'd like to suggest the following new module: fprintftime-check. It uses the same infrastructure as fprintftime (i.e. #include "nstrtime,c") to implement a new function: int fprintftime_check (const char *format, const char** err_ptr); This function enables syntax-check of the format

Re: random module linking problem on mingw ?

On 2018-12-16 8:29 a.m., Bruno Haible wrote: For me, with a gnulib testdir created through ./gnulib-tool --create-testdir --dir=../testdir1 --single-configure random I still get a link error in test-random. "nm" shows why: random.o defines __initstate and __setstate, where test-random.c

Re: [platform-testers] new snapshot available: grep-3.1.51-e767

On 2018-12-18 5:49 a.m., Bruno Haible wrote: Hi Assaf, In you reported: CYGWIN_NT-10.0 2.11.1(0.329/5/3) (x86_64) (with one gnulib failure: test-wctype-h) Can you please give more details? With an older version of

Re: random module linking problem on mingw ?

Hello, On 2018-12-14 3:36 p.m., Paul Eggert wrote: This does not ring a bell with me. Presumably the "# define __random_r random_r" business in lib/random_r.c and lib/stdlib.in.h also need to be done for random and srandom in lib/random.c and lib/stdlib.in.h? Thanks for the hint. The

random module linking problem on mingw ?

Hello, Around June 2018, there were few changes to the random module: == 6979c258b random_r: do not crash if state is unaligned dc4b9a1f9 random_r: omit unnecessary include 137dda358 random, random_r: merge from glibc == After uprgading gnulib and re-building (towards a new release), and

Re: bug#6816: df bug on 64-bit Solaris (need to use getextmntent)

Hello Bruno, On 2018-10-12 10:17 a.m., Bruno Haible wrote: David Wood wrote: At this point, me->me_dev contains a wrongly packed (32-bit) device number, which forces the find_mount_point() code path (causing other unpleasantries). The following patch against coreutils v8.5 fixes the problem:

Re: mountlist: platform comments

Hello Bruno, On 11/10/18 03:31 PM, Bruno Haible wrote: The platform comments in mountlist.c and ls-mntd-fs.m4 are not very informative any more. E.g. What is "BSD4.4" nowadays? Why is "Solaris" not mentioned? Here's what I found by compiling a testdir on today's platforms and looking for

Re: memory leaks in gnulib tests (for ASAN/LINT)

in the future). regards, - assaf >From 8769b66e1e05f5fdb46221f4a49cef58abaa0b0c Mon Sep 17 00:00:00 2001 From: Assaf Gordon Date: Wed, 10 Oct 2018 17:01:43 -0600 Subject: [PATCH] samacls tests: free memory under lint Avoids false-positives under ASAN and provides better usage examples. Initia

mountlist: support windows

omed, - assaf >From d1c3e9a61e7c1e9a6bab2b5198d24391e309adc0 Mon Sep 17 00:00:00 2001 From: Assaf Gordon Date: Wed, 10 Oct 2018 14:08:42 -0600 Subject: [PATCH 1/2] mountlist tests: add mountlist-tests module Call read_file_system_list, print the list, and free the entries. Typical output example: $ ./gnulib-tool -creat

Re: bug#6816: df bug on 64-bit Solaris (need to use getextmntent)

(triaging old bugs) Hello, On 15/09/10 04:18 PM, Eric Blake wrote: On 08/06/2010 01:56 PM, Wood, David wrote: From mnttab(4) on Solaris 10: [...] At this point, me->me_dev contains a wrongly packed (32-bit) device number, which forces the find_mount_point() code path (causing other

memory leaks in gnulib tests (for ASAN/LINT)

Hello gnulib, 'deltatau' recently reported 3 memory leaks detected in gnulib's test in sed [1]. This was found using our recent ASAN build feature [2]. [1] https://bugs.gnu.org/32685 [2] https://git.savannah.gnu.org/cgit/sed.git/commit/?id=0cc0ade4237b8db69f5253c3d933f9890b698f4d It is a

Re: two (and a half) more crashes in regex module

Hello, On 12/09/18 12:02 AM, Assaf Gordon wrote:    $ echo 1 |  grep -E "(\'|^)(\1|)"    grep: regexec.c:1375: pop_fail_stack: Assertion `num >= 0' failed.    Aborted I don't have a fix yet, but I reduced the crash to this interesting case: $ echo 1 | grep -E '(^|$)\1'

two more crashes in regex module

ors, rerun with: -v ==7809== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) /* gnulib regex crash reproducer Copyright (C) 2018 Assaf Gordon License: GPLv3-or-later */ #define _GNU_SOURCE #include #include #include #include #include int main(void) { const char *input =

two (and a half) more crashes in regex module

gex crash reproducer Copyright (C) 2018 Assaf Gordon License: GPLv3-or-later */ #define _GNU_SOURCE #include #include #include #include #include int main(void) { const char *input = "1AA"; static struct re_pattern_buffer regex; #if 1 /* Crash 1: with gnulib:

Re: bug#32592: heap-use-after-free in regex module

Thank you all for the review and comments. On Thu, Sep 6, 2018 at 1:18 AM, Paul Eggert wrote: > What a coincidence that we would find two bugs right next to each other, > huh?... > > I filed a bug report against glibc, and unless there's an objection I would > like to fix both bugs in glibc and

Re: bug#32592: heap-use-after-free in regex module

hange for > "check for allocation errors and bail out if needed". Thanks! I initially had a check for REG_NOERROR there, but removed it. Attached an updated patch without the outdated comment. -assaf >From 3e6bc87d1a8dc6e22c6d60d06aef0b0b6cb03a49 Mon Sep 17 00:00:00 2001 From: A

Re: bug#32592: heap-use-after-free in regex module

Hello, Assuming the gnulib bugfix is valid (in my previous email), I suggest adding the following test to sed (after updating gnulib). comments welcomed, - assaf >From bc2794c76cd4202df5172bdbe364a4006e6edbe6 Mon Sep 17 00:00:00 2001 From: Assaf Gordon Date: Wed, 5 Sep 2018 18:58:55 -0

Re: bug#32592: heap-use-after-free in regex module

Hello, On Wed, Sep 5, 2018 at 12:32 AM Assaf Gordon wrote: >>>> On 04/09/18 07:02 PM, Saito Takaaki wrote:>>> https://ideone.com/Sq5xJX>>>>>> I hope this helps even a bit.>>>> The linked snippet you provided exposed a heap-use-after-fr

bug#32592: heap-use-after-free in regex module (was: s with i modifier seems to work incorrectly)

(adding gnulib) On 04/09/18 07:02 PM, Saito Takaaki wrote: [... discussing a sed bug ...] However, a friend showed me a more complex case which is problematic even with sed 4.4 on ideone. The last two lines of the output (for the identical input lines) are particularly interesting.

Re: regex_internal: uninitialized memory access (long)

Hi, On 25/08/18 01:46 AM, Paul Eggert wrote: Please try the attached gnulib patch, which should fix the problem in a portable way. Modern GCC optimizes the clear code just as well as the confusing code, so we might as well write it clearly. Thanks for the quick fix and explanation. The patch

Re: regex_internal: uninitialized memory access (long)

Hello, On 13/08/18 03:51 PM, Assaf Gordon wrote: I suspect there is an uninitialized memory access deep inside regex_internal.c under very particular circumstances. (continuation of https://lists.gnu.org/r/bug-gnulib/2018-08/msg00071.html ) I've pin-pointed the change that causes

regex_internal: uninitialized memory access (long)

Hello all, I suspect there is an uninitialized memory access deep inside regex_internal.c under very particular circumstances. This was first reported by "project-repo " as part of his fuzzing efforts, here: https://lists.gnu.org/r/sed-devel/2018-08/msg00017.html I've been able to pinpoint the

Re: [PATCH]: regex: fix memory leak in multibyte character set regexes.

dfamalloc()' should be dfafree'd + free'd. A free() call is missing in one instance. Patch attached, comments welcomed. - assaf >From 4abc3de62c937752327b08b0618426ce4018363d Mon Sep 17 00:00:00 2001 From: Assaf Gordon Date: Wed, 1 Aug 2018 22:14:21 -0600 Subject: [PATCH] dfa: fix memory leak

[PATCH]: regex: fix memory leak in multibyte character set regexes.

.6+0x202e0) == I think the attached patch fixes the issue. Comments welcomed. -assaf >From b1c219384e22fa97ee6fbad7f831b2e18c54 Mon Sep 17 00:00:00 2001 From: Assaf Gordon Date: Tue, 31 Jul 2018 12:18:26 -0600 Subject: [PATCH] regex: fix memory leak

Re: af_alg benchmarks and performance

Hello Matteo and all, Let me emphasize that I'm not against this feature, but I just think it should be disabled by default, and enabled explicitly with a "configure" flag when downstream users want it and deemed it worthwhile. On 09/05/18 02:57 AM, Matteo Croce wrote: [...] All this kernel

Re: [PATCH v3 0/4] Use AF_ALG in checksum utilities

Hello Paul, On Mon, May 07, 2018 at 12:36:43AM -0700, Paul Eggert wrote: > Assaf Gordon wrote: [...] > > It won't matter to a single user on a desktop, but imagine > > a shared server at a university, when all of a sudden a sysadmin > > might see a very very high %SYS load

Re: af_alg benchmarks and performance

Hello, On Tue, May 08, 2018 at 02:20:07AM +0200, Bruno Haible wrote: > The following approaches come to mind: [...] > * Use the kernel-provided meta-info about the algorithms to decide whether > to use the kernel API. > > In detail: Read /proc/crypto at run time. It consists of

Re: af_alg benchmarks and performance

Hello Bruno and all, On Tue, May 08, 2018 at 01:10:52AM +0200, Bruno Haible wrote: > Let me try to summarize. Thanks for writing this - informative and helpful. > * We need to consider each of the algorithms md5, sha1 sha256 separately, > because each algorithm has a different

Re: [PATCH v3 0/4] Use AF_ALG in checksum utilities

Hello Bruno and all, On Sun, May 06, 2018 at 12:31:36PM +0200, Bruno Haible wrote: > Assaf suggested to let it turned off by default, but I prefer to turn it on > by default because I'd still suggest turning it off by default to be more conservative. Few things to consider: > * All known

Re: [PATCH v2 1/4] sha1sum: use AF_ALG when available

Hello Matteo, On Wed, Apr 25, 2018 at 01:26:08PM +0200, Matteo Croce wrote: > Linux supports accessing kernel crypto API via AF_ALG since > version 2.6.38. Coreutils uses libcrypto when available and fallbacks to > generic C implementation of various hashing functions. Not exactly: coreutils

Re: localename: add support for musl libc

Hello Bruno, On Sat, Feb 24, 2018 at 01:01:07PM +0100, Bruno Haible wrote: > On Alpine Linux 3.7.0, which uses musl libc, I see this test failure: [...] > diff --git a/lib/localename.c b/lib/localename.c > index 2133cbc..74c8ee0 100644 > --- a/lib/localename.c > +++ b/lib/localename.c > @@ -40,7

Re: Fwd: bug#27269: Sed --in-place is messing NTFS file permissions

Hi Paul, On 2017-11-18 03:46 PM, Paul Eggert wrote: Assaf Gordon wrote: set_permissions uses the USE_ACL #define to either call "set_acls" or call chmod/fchmod directly [4]. It vaguely sounds like a Gnulib bug if set_permissions isn't calling set_acls when it should. However, yo

Fwd: bug#27269: Sed --in-place is messing NTFS file permissions

e: Wed, 15 Nov 2017 03:43:30 -0700 From: Assaf Gordon <assafgor...@gmail.com> To: Maiko Cezar Rodrigues Costa <maiko.ce...@gmail.com>, 27...@debbugs.gnu.org Hello, On 2017-11-15 02:23 AM, Assaf Gordon wrote: On 2017-06-06 08:45 PM, Maiko Cezar Rodrigues Costa wrote: Hi, I've a probl

Re: [PATCH] Implement SM3 hash algorithm in gnulib and the computing tool in coreutils.

Hello, On 2017-10-24 04:09 AM, Bruno Haible wrote: Indeed, we don't have many crypto experts on the gnulib mailing lists. Therefore, I too would like the crypto experts on the libgcrypt or openssl mailing lists to evaluate the SM3 algorithm and your code first, before we can accept it in

OpenGrok for gnulib (and other software)

Hello, I'm running a small OpenGrok* server with various software including gnulib, glibc, coreutils and other libraries/programs: https://opengrok.housegordon.com/ The gnulib source code is here: https://opengrok.housegordon.com/source/xref/gnulib/ Repositories are updated from git twice

GNU Time updates (slightly off-topic)

Hello, It's time to update GNU time... As the first step, I've converted the code to use modern gnulib structure and added the standard testing framework. Secondly, I've fixed few issues based on downstream Debian patches. There shouldn't be any functional changes in the current code. Later I

FALLTHROUGH warning in quotearg.c with gcc-7.1

Hello, Pulling the latest gnulib and compling with gcc-7.1, I'm seeing the following warning: gcc-7.1 -DLOCALEDIR=\"/usr/local/share/locale\" -DHAVE_CONFIG_H -I. -Ilib -I./lib -Isrc -I./src -g -O2 -MT lib/quotearg.o -MD -MP -MF $depbase.Tpo -c -o lib/quotearg.o lib/quotearg.c &&\ mv -f

Re: automated CI testing

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 ? [...] Therefore what is more valuable for gnulib (IMO) is automated testing on 20 different platforms. Of course everybody

Re: bug#25390: Segfault with sed 4.3

tag 25390 fixed close 25390 thanks Hello, Thanks again for everyone who reported, fixed and improved sed and dfa/gnulib. sed's update to latest gnulib is pushed here: http://git.savannah.gnu.org/cgit/sed.git/commit/?id=44d99bf5c98ea77de0addf55ad7fe281396de996 followed by the new test:

switch to C99 breaks DFA tests

Hello all, I noticed that some standalone tests now fail because they use c99 constructs. For example: ./gnulib-tool --create-testdir --dir test1 dfa cd test1 ./configure make fails with: dfa.c: In function ‘fillset’: dfa.c:727:3: error: ‘for’ loop initial declarations

Re: bug#25390: Segfault with sed 4.3

Hello all, > On Jan 9, 2017, at 09:11, Norihiro Tanaka wrote: > > Sorry, I adjusted commit log, New patch does not change > testsuite/Makefile.tests. > <0001-tests-new-test-for-dfa-crash-bug.patch> Paul, Thank you for the quick fix. Norihiro, Thank you for the dfa

Re: bug#25390: Segfault with sed 4.3

Hello, > On Jan 8, 2017, at 00:31, S. Gilles wrote: > >> I have a reliable segfault with (vanilla) sed 4.3 which does not appear >> on (vanilla) 4.2.2. Thank you for the report! I can confirm the segfault is reproducible. The immediate cause is somewhere in gnulib's DFA

Re: suggested improvements to parse-datetime's debug messages ('date --debug')

> On Jan 2, 2017, at 07:25, Pádraig Brady <p...@draigbrady.com> wrote: > > On 02/01/17 02:25, Assaf Gordon wrote: >> Hello, >> >> Attached are four small bug fixes and two additions to the debug messages in >> parse-datetime.y (used in 'date

suggested improvements to parse-datetime's debug messages ('date --debug')

Hello, Attached are four small bug fixes and two additions to the debug messages in parse-datetime.y (used in 'date --debug'). The commit message for each commit gives a detail example of how/when it is used. There are no changes to the parsing, only to the debug messages. Comments and

Re: what platforms are you testing on?

Hello Bruno and all, On Sun, Oct 16, 2016 at 4:43 AM, Bruno Haible wrote: > Can each of you please give a list of platforms to which you have access and > on which you frequently or occasionally test gnulib modules? I run automated testing for tarballs posted on

Re: bug#24256: new module for grep's DFA matcher

Hello Jim and all, > On Sep 10, 2016, at 14:44, Jim Meyering wrote: > > Finally, here is a similar change, but now for gnu sed. For it, I also > had to make some small code changes to adapt to the new > localeinfo.[ch] and to the dfasyntax API change. I'll wait a day or so >

Re: suggested feature: "date --debug" - print date parsing diagnostics

> On Aug 19, 2016, at 16:48, Pádraig Brady wrote: > > Looks good and pushed. Thanks! I'll send the coreutils' corresponding patch next. regards, - assaf

Re: suggested feature: "date --debug" - print date parsing diagnostics

> On Aug 12, 2016, at 04:37, Pádraig Brady wrote: > > There's precedent for .2() versions of functions, like renameat2() etc. > How about we pass an unsigned int flags, instead of bool, in case we ever > need to extend in future? Attached a version with 'unsigned in

Re: suggested feature: "date --debug" - print date parsing diagnostics

> On Aug 10, 2016, at 05:59, Pádraig Brady wrote: > > Those look good to squash and apply, > modulo s/setftime/strftime/ in modules/parse-datetime Thank you for the review. Attached a squashed patch. I kept the name of the new function as 'parse_datetime2' (if that's

Re: suggested feature: "date --debug" - print date parsing diagnostics

upon, I'll send the corresponding 'date' patch to coreutils). regards, - assaf Assaf Gordon (7): parse-datetime.y: remove DEBUG0 parse-datetime.y: remove DEBUG, PROGRESS macros parse-datetime.y: remove DEBUG_PRINT_CURRENT_TIME macro parse-datetime.y: remove DEBUG_PRINT_RELATIVE_TIME macro

gcc 6.1.1 compilation error due to -Werror=null-dereference in obstack.c

Hello, Not sure if this has been reported yet: On Fedora 24 with gcc 6.1.1, compiling coreutils from git (thus with -Werror) fails with the error below. Possibly due to GCC not understanding that if 'new_chunk' is NULL and 'obstack_alloc_failed_handler' is called, it won't return (in

Re: suggestion: minor change to maint.mk's 'coverage' targets to help develop coverage tests faster

Hello, Thank you for the review. Attached an improved patch (also marks the coverage targets as phony). regards, - assaf 0001-maint.mk-Add-intermediate-coverage-target.patch Description: Binary data

suggestion: minor change to maint.mk's 'coverage' targets to help develop coverage tests faster

Hello, I'd like to suggest the following minor change to the 'coverage' targets in 'maint.mk'. With it, when improving coverage of the test suite, a developer can bootstrap the coverage build with 'make coverage', then add individual test, then run "make re-coverage" and just re-generate the

Re: problem in gperf makefile rules

On 12/18/2015 05:50 PM, Daiki Ueno wrote: Assaf Gordon <assafgor...@gmail.com> writes: I'm encountering some build errors during 'make' in projects using gnulib, and I suspect it has something to do with this commit: gperf: respect silent rules http://git.savannah.gnu.or

problem in gperf makefile rules

Hello, I'm encountering some build errors during 'make' in projects using gnulib, and I suspect it has something to do with this commit: gperf: respect silent rules http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=30f4290277444b1d4825a42c9a33f2c3c7fe310a The symptom I've found is

Re: Buggy ceill on OpenBSD, and possible gnulib test problem

s for gnulib are now in place. Thanks, - assaf >From a2abacb8133f07c9aa629db03a8e9008d0d15931 Mon Sep 17 00:00:00 2001 From: Assaf Gordon <assafgor...@gmail.com> Date: Tue, 8 Sep 2015 19:43:32 -0400 Subject: [PATCH] ceill: detect buggy OpenBSD implementation * m4/ceill.m4: detect buggy

Buggy ceill on OpenBSD, and possible gnulib test problem

9000693c14ff929a302892c2bae1cd76aa233922 Mon Sep 17 00:00:00 2001 From: Assaf Gordon assafgor...@gmail.com Date: Wed, 12 Aug 2015 13:56:32 -0400 Subject: [PATCH] ceill: detect buggy OpenBSD implementation * m4/ceill.m4: detect buggy openBSD implementation which returns zero for small values (discussed at http

Re: Buggy ceill on OpenBSD, and possible gnulib test problem

On Wed, Aug 12, 2015 at 11:26:33AM -0700, Paul Eggert wrote: Assaf Gordon wrote: 2. Similar to 'gl_cv_func_expl_buggy' in 'm4/expl.m4', add 'gl_cv_func_ceill_buggy' in 'm4/ceill.m4'. ... Can you redo the patch so that it detects the bug with the default CFLAGS and GCC? Something like

[no subject]

Hello, This tiny patch fixes a wrong regex in the gawk script 'build-aux/pmccabe2html'. The commands replace '' with 'amp;', '' with 'gt;' and '' with 'lt;', but I think the actual replacement doesn't work properly. A contrived example: $ echo '==' | gawk '{gsub(,\gt;,$0);print}' gawk:

Note about gnulib's roundl/expl under NetBSD (limited precision leading to segfault)

Hello, This is not a bug, but it took me a long time to troubleshoot, so I figured I'll share it (perhaps save someone else some time). In short: under NetBSD, because of defaulting to 'double' precision (instead of 'long double', as nicely documented in gunlib's fpucw.h file), the roundl

Re: [PATCH] stdio: fix probe on mingw under gcc 5.1

Hello, I'm encountering a similar/related issue with PRIdMAX on mingw32-gcc 4.8.2. In short, when using gnulib in my project and cross-compiling with mingw32-gcc 4.8.2 somehow the PRIdMAX becomes lld instead of I64d. I was able to reproduce it with GNU Hello (long details below). perhaps

Re: [PATCH] stdio: fix probe on mingw under gcc 5.1

Hello Eric, Thanks for your quick reply and fix. I've found one more issue which I'm not sure how to solve - interplay between gcc/mingw/inttypes/gnulib: The format string to error(). In theory (if I understand correctly), printf() and error() should accept the same format specifiers, thus

Re: [PATCH] gendocs.sh: default to a common CSS style sheet for HTML output

Hello, On Mar 31, 2015, at 11:51, Ludovic Courtès l...@gnu.org wrote: ... http://gnu.org/s/gnulib/manual.css, and then to update gendocs.sh to refer to that by default. Objections? Suggestions? This URL results in two redirections, perhaps it'll better to use the expanded version?

Re: gnulib - test-getcwd failure on Mac OS X

Hello, On Nov 30, 2014, at 6:09, Pádraig Brady p...@draigbrady.com wrote: For context, gnulib-tests/test-getcwd.c is failing on Mac OS X with exit(7)... I've tried forcing AT_FDCWD to zero in 'test-getcwd.c' on Mac-OS, and it still fails with exit code 7, due to errno=2 (ENOENT). So perhaps my

build-aux/gnu-web-update-doc-update-git

Hello gnulib developers, I'm experimenting with GIT-based repositories for the web pages at http://www.gnu.org/software/XXX . For details see here: http://lists.gnu.org/archive/html/savannah-hackers-public/2014-11/msg1.html The current gnulib script 'build-aux/gnu-web-update-doc-update'

Re: build-aux/gnu-web-update-doc-update-git

Hello, On 11/06/2014 07:47 PM, Karl Berry wrote: My feedback is that instead of being a separate script that is mostly the same, it seems like it would be better as an option. Attached is an updated patch, this time adding -G/--git option to the existing script 'build-aux/gnu-web-doc-update'

Portability testing using pre-configured VMs

Hello, To ease portability testing of GNU software, I've created a collection of virtual-machines of POSIX-compatible, Free-Software operating systems. These are pre-configured with programs required for building autotools-based projects. If anyone is interested in using them, downloads and

Minor portability problems: gnulib/coreutils on MINIX3

Hello, Another exotic portability report: I'm experimenting with compiling GNU Coreutils on MINIX3 (which is supposed to be POSIX-compliant minix kernel with NetBSD userspace). I'm compiling coreutils-8.23, with: $ uname -a Minix 10.0.2.15 3.3.0 Minix 3.3.0 (GENERIC) i386 $ cc -v

Minor portability compilation error: '#include_next' problem with TCC (Tiny C Compiler)

Hello, I've encountered a compilation error when compiling gnulib with TCC ( Tiny C Compiler, http://bellard.org/tcc/ ): it seems the #include_next is not working properly, but m4/include_next.m4 does not detect it. Tested with TCC version 0.9.26 from the standard debian/stable package. To

Re: Minor portability compilation error: '#include_next' problem with TCC (Tiny C Compiler)

On 09/15/2014 01:31 PM, Assaf Gordon wrote: I've encountered a compilation error when compiling gnulib with TCC ( Tiny C Compiler, http://bellard.org/tcc/ ): it seems the #include_next is not working properly, but m4/include_next.m4 does not detect it. Tested with TCC version 0.9.26 from

Portable printing of 'size_t' (especially with mingw for windows)

Hello, I'm not sure if this is a gnulib question per-se, but I'm hopeful you could perhaps advise me. I use the following (or similar) code in my project: size_t line=42; error(EXIT_FAILURE, 0, _(error in line %zu), line); The %zu works for 'size_t' on all unix-like systems I've

Re: Portable printing of 'size_t' (especially with mingw for windows)

On 09/11/2014 11:48 AM, Pádraig Brady wrote: I wonder if there's a definition in inttypes.h or similar that would be a correct one to use, or if there's another portable way to compile it. I've some notes on printing int values at: http://www.pixelbeat.org/programming/gcc/int_types/

tests fail: test-lock and test-thread_create with gcc 4.6/4.8

Hello, On Ubuntu 14.04 LTS with GCC 4.6.4 and 4.8.2, the tests test-lock and test-thread_create fail. They do not fail on same system with GCC 4.4.7 or Clang-3.3 . Confirmed also by Daiki Uenu: http://lists.gnu.org/archive/html/bug-libunistring/2014-09/msg5.html From a brief look it

test-lock stuck on FreeBSD

Hello, On FreeBSD 10, 9.3, 8.4 (running inside kvm), the test test-lock sometime gets stuck. It was found through libunistring but I've also reproduced it with the latest gnulib directly (v0.1-210-g4738e5a), by doing: ./gnulib/gnulib-tool --create-testdir --dir=test-thread --with-tests

Re: tests fail: test-lock and test-thread_create with gcc 4.6/4.8

On 09/04/2014 06:00 PM, Paul Eggert wrote: Assaf Gordon wrote: COLLECT_GCC=gcc-4.8 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper Yes, it appears to be a bug in the Ubuntu link-time optimization. Could you please report it to Ubuntu? In the meantime I have installed

Re: test-lock stuck on FreeBSD

On 09/04/2014 06:02 PM, Paul Eggert wrote: I'm afraid you're going to have to debug this one, as I don't have easy access to FreeBSD SadlyI will not be able to devote time for that in the near future. So it will have to wait. (yes, I know I could set it up in a virtual machine, but it's just

  1   2   >