Re: recent gnulib has problems with read, write and close within structs

sorry, just didn't understand it correctly. I am going to try for the next release. On Mon, Sep 14, 2020 at 8:54 PM Bruno Haible wrote: > > Joël Krähemann wrote: > > How can I fix it in my code? > > What do you mean? Does this fix not work? >

Re: Trying to bootstrap my project, distcheck doesn't configure

Hi Bruce, It would help if you would give a pointer to the source code you are trying to bootstrap. Because a single line in Makefile.am or configure.ac can have a big effect. > >>> do_not_make_me_la_SOURCES += timespec.c > >>> do_not_make_me_la_SOURCES += unistd.c > >> which trigger error messag

Re: Trying to bootstrap my project, distcheck doesn't configure

Sorry, Mathieu, I can now see I sent it to the wrong list. On 9/14/20 11:33 AM, Mathieu Lirzin wrote: I'm hitting this that I've never seen before: $ grep do_not_make_me au*bld/autoopts/Makefile.am do_not_make_me_la_LIBADD += @LTALLOCA@ do_not_make_me_la_DEPENDENCIES += @LTALLOCA@ EXTRA_do_not_m

Re: Question about C sscanf and unicode

Jose Kahan wrote: > I am a contributor to an mail hypertext archiving system called > hypermail [1], which is written in C. > > Recently a bug was raised that one of its parsers had problems > when the input string had a nbsp. As you may imagine from my subject, > this is because that parser uses

Re: recent gnulib has problems with read, write and close within structs

Joël Krähemann wrote: > How can I fix it in my code? What do you mean? Does this fix not work? Bruno

Question about C sscanf and unicode

Hi, I am a contributor to an mail hypertext archiving system called hypermail [1], which is written in C. Recently a bug was raised that one of its parsers had problems when the input string had a nbsp. As you may imagine from my subject, this is because that parser uses sscanf and the nbsp corre

Re: recent gnulib has problems with read, write and close within structs

John Darrington wrote: > I don't think this will solve all problems. > > For example if you have: > > > > #include > > struct foo > { > void write (char *); > }; > > func (struct foo *f) > { >f->write ("hello"); > } > > > > then one will get an error similar to "rpl_write is n

Re: recent gnulib has problems with read, write and close within structs

Joël Krähemann wrote: > I would be interested in why it was working prior? Prior, Gnulib did '#define write rpl_write' only when - the Gnulib module 'write' was in use, either directly or indirectly, - and the platform's write() needs a workaround [1]. Now, we're doing '#define write _write'

Re: recent gnulib has problems with read, write and close within structs

How can I fix it in my code? My mingw32 compiler is $ x86_64-w64-mingw32-gcc --version x86_64-w64-mingw32-gcc (GCC) 10-posix 20200525 Copyright (C) 2020 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY

Re: recent gnulib has problems with read, write and close within structs

I would be interested in why it was working prior? On Sun, Sep 13, 2020 at 11:11 PM Bruno Haible wrote: > > Hi Joël, > > > Because recent gnulib has problems with read, write and close as > > struct fields. I am still using: > > > > gnulib$ git log > > commit 2d431ac35c4943a3655c07ba91870d2323321

Re: bug#40634: Massive pattern list handling with -E format seems very slow since 2.28.

On Sun, Sep 13, 2020 at 7:03 PM Paul Eggert wrote: > On 9/11/20 11:41 PM, Jim Meyering wrote: > >> https://bugs.gnu.org/40634#32 > >> > >> I'll try to take a look at the later patch. > > > > Oh! Glad you spotted that. > > I took a look and the basic idea sounds good though I admit I did not check

Re: recent gnulib has problems with read, write and close within structs

On Mon, Sep 14, 2020 at 01:54:14PM +0200, John Darrington wrote: > On Sun, Sep 13, 2020 at 11:11:55PM +0200, Bruno Haible wrote: > > > The workaround is simple: Make sure that you include the corresponding > file - > here - before the struct definition. That is, in this case

Re: [PATCH 1/3] dfa: fix dfa-heap-overrun failure

On Mon, 14 Sep 2020 00:28:32 -0700 Paul Eggert wrote: > On 9/14/20 12:13 AM, Norihiro Tanaka wrote: > > > when (i >= d->follows[i].elems[j].index), it seems that > > map[d->follows[i].elems[j].index] has been already set a value more than 0. > > > > What case violates this assumption? > > Than

Re: recent gnulib has problems with read, write and close within structs

On Sun, Sep 13, 2020 at 11:11:55PM +0200, Bruno Haible wrote: The workaround is simple: Make sure that you include the corresponding file - here - before the struct definition. That is, in this case, at the beginning of ags/object/ags_application_context.h, add #

Re: parse-datetime: Fix compilation error with bison 3.7

Bruno Haible writes: > (III) Use portable make syntax and still allow parallel make. > > Below I apply the approach (III). > > [1] https://lists.gnu.org/archive/html/bug-make/2019-05/msg00020.html > [2] https://lists.gnu.org/archive/html/bug-make/2020-09/msg8.html > > > 2020-09-13 Bruno Ha

Re: [PATCH 1/3] dfa: fix dfa-heap-overrun failure

On 9/14/20 12:13 AM, Norihiro Tanaka wrote: when (i >= d->follows[i].elems[j].index), it seems that map[d->follows[i].elems[j].index] has been already set a value more than 0. What case violates this assumption? Thank you for looking into this. I ran into the problem with the dfa-heap-overru

Re: [PATCH 1/3] dfa: fix dfa-heap-overrun failure

On Sun, 13 Sep 2020 18:41:49 -0700 Paul Eggert wrote: > * lib/dfa.c (reorder_tokens): When setting > map[d->follows[i].elems[j].index], instead of incorrectly assuming > that (i < d->follows[i].elems[j].index), use two loops, one to set > the map array and the other to use it. The incorrect as