*printf: Avoid "expanded before it was required" warning

In GNU libtextstyle I'm seeing this warning: configure.ac:71: warning: AC_REQUIRE: `gl_SNPRINTF_TRUNCATION_C99' was expanded before it was required configure.ac:71: http://www.gnu.org/software/autoconf/manual/autoconf.html#Expanded-Before-Required gnulib-m4/vasnprintf.m4:15:

Re: Unused parameter warnings

-static size_t +static size_t _GL_ATTRIBUTE_PURE gl_tree_size (gl_list_t list) Although changes like these don't break anything, I generally don't bother doing them if only older GCCs warn about a missing attribute, under the theory that people stuck with older compilers can build with

Re: stack bounds

Paul Eggert wrote: > That being said, it does look like a reliability win if we start using > -fstack-clash-protection on platforms like Fedora x86-64 that support it and > do > not enable it by default. Perhaps we should have a Gnulib or Autoconf macro > that > does that. Yes, such a macro

Re: Unused parameter warnings

On Sun, Oct 11, 2020 at 7:11 PM Paul Eggert wrote: > > > -static size_t > > +static size_t _GL_ATTRIBUTE_PURE > > gl_tree_size (gl_list_t list) > > Although changes like these don't break anything, I generally don't bother > doing > them if only older GCCs warn about a missing attribute, under

Re: stack bounds

On 10/11/20 3:08 PM, Bruno Haible wrote: But do you have an overview which targets are meant in the doc? Unfortunately not. I expect it'd have to be determined from the comments in GCC, and it might also need info from various OSes and/or linkers.

Re: _Atomic

On 10/10/20 3:39 PM, Bruno Haible wrote: GCC 4.9.x is such a compiler that is non-C11 but supports _Atomic. Oh, I was thinking the other way: a compiler that says it's C11 but doesn't support _Atomic. I wrote my thoughts backwards, though. If Gnulib code won't use _Atomic when compiled with

Re: _Atomic

Paul Eggert wrote: > Oh, I was thinking the other way: a compiler that says it's C11 but doesn't > support _Atomic. I haven't found such a compiler in my testing [1]. If one appears, we can add an ad-hoc test or an Autoconf test. Bruno [1]

hash, xhash: modernize

Hi, It has been reported today that looking at the 'hash' module made Marc guess incorrectly what is desired coding style and terminology in Gnulib. 1) regarding where to documented exported functions of a module 2)

Re: [New module] Persistent Hash Array Mapped Tries (HAMTs)

Am So., 11. Okt. 2020 um 03:28 Uhr schrieb Bruno Haible : > > Hi Marc, > > Some comments: > > * GL_HAMT_THREAD_SAFE can be defined to 1 not only if > __STDC_VERSION__ >= 201112 && ! defined __STD_NO_ATOMICS__ > but also if > __GNUC__ + (__GNUC_MINOR >= 9) > 4 Fixed. > (see the other

Re: HAMT iterators

Hi Marc, > > You can see that there is an initial function call > > HASH-TABLE-ITERATOR > > upfront, and then a function call to HASH-TABLE-ITERATE in each > > round > > of the loop. > > > > This principle makes it possible to iterate e.g. through a hash > >

Re: out-of-memory handling

Am So., 11. Okt. 2020 um 12:54 Uhr schrieb Bruno Haible : > > The bigger problem is that it mustn't make the code slower for the > > 99,9% of the use cases where there is either enough memory or > > calling xalloc_die is the only reasonable action. > > OK. When we add hamt as a possible

Re: HAMT iterator

Am So., 11. Okt. 2020 um 13:02 Uhr schrieb Bruno Haible : > > Hi Marc, > > > I am going to implement the following iterator API as well: > > > > /* An alternative interface to iterating through the entry of a hamt > >that does not make use of a higher-order function like > >hamt_do_while

Re: out-of-memory handling

Am So., 11. Okt. 2020 um 13:56 Uhr schrieb Bruno Haible : > > Marc Nieper-Wißkirchen wrote: > > I am not so convinced of whether it makes sense to create a > > gl_set/gl_map frontend for this hamt implementation. > > Wikipedia [1] lists some advantages of HAMTs even without the persistence. > > >

Re: HAMT iterator

Am So., 11. Okt. 2020 um 14:14 Uhr schrieb Bruno Haible : [...] > > > > /* Return an independent copy of ITER that is initially in the same > > > >state. */ > > > > extern Hamt_iterator *hamt_iterator_copy (Hamt_iterator *iter); > > > > > > Then a copy function is not needed, because the

Re: HAMT iterator

Marc Nieper-Wißkirchen wrote: > > - If someone creates a derivative of the HAMT, the iterator won't > > be affected, right? ("persistence") > > Yes. OK, that's one thing to document. > > So, what is the scenario where increasing the reference count will make > > a difference? > > If you

Re: [New module] Persistent Hash Array Mapped Tries (HAMTs)

I am going to implement the following iterator API as well: /* An alternative interface to iterating through the entry of a hamt that does not make use of a higher-order function like hamt_do_while uses the opaque Hamt_iterator type. */ typedef struct hamt_iterator Hamt_iterator; /*

Re: out-of-memory handling

Marc Nieper-Wißkirchen wrote: > > 2) We have a dilemma regarding use of malloc vs. xmalloc. While modules > > meant for use in programs can readily use xmalloc, modules meant for > > use > > (also) in libraries cannot use xmalloc, since a library is not supposed > > to terminate

Re: HAMT iterator

Hi Marc, > I am going to implement the following iterator API as well: > > /* An alternative interface to iterating through the entry of a hamt >that does not make use of a higher-order function like >hamt_do_while uses the opaque Hamt_iterator type. */ > typedef struct hamt_iterator

Re: [PATCH] pthread_sigmask: fix implicit declaration of 'pthread_sigmask'

KO Myung-Hun wrote: > * lib/signal.in.h [__KLIBC__]: Include . > * lib/sys_select.in.h [__KLIBC__]: Do not include . Thanks. Applied. Bruno

Re: out-of-memory handling

Marc Nieper-Wißkirchen wrote: > I am not so convinced of whether it makes sense to create a > gl_set/gl_map frontend for this hamt implementation. Wikipedia [1] lists some advantages of HAMTs even without the persistence. > It is optimized > for the persistence (otherwise, use ordinary hash

Re: HAMT iterator

Marc Nieper-Wißkirchen wrote: > > > /* Return an independent copy of ITER that is initially in the same > > >state. */ > > > extern Hamt_iterator *hamt_iterator_copy (Hamt_iterator *iter); > > > > Then a copy function is not needed, because the user's program can do > > > > Hamt_iterator

Re: HAMT iterator

Marc Nieper-Wißkirchen wrote: > > > I am going to implement the following iterator API as well: > > > > > > /* An alternative interface to iterating through the entry of a hamt > > >that does not make use of a higher-order function like > > >hamt_do_while uses the opaque Hamt_iterator

Re: HAMT iterator

Am So., 11. Okt. 2020 um 14:04 Uhr schrieb Bruno Haible : > > Marc Nieper-Wißkirchen wrote: > > > > /* Return an independent copy of ITER that is initially in the same > > > >state. */ > > > > extern Hamt_iterator *hamt_iterator_copy (Hamt_iterator *iter); > > > > > > Then a copy function is

Re: HAMT iterators

Am So., 11. Okt. 2020 um 12:29 Uhr schrieb Bruno Haible : > The recursion across hamt_do_while / entry_do_while / subtrie_do_while / > bucket_do_while builds up a stack whose essential contents is a set of > indices, each at most 5 bits large, with a total of SIZE_WIDTH bits. > In other words,

Re: lib/fwriting.c

Tim Rice wrote: > On line 24 of lib/fwriting.c we see > /* This file is not used on systems that have the __fwritable function, > > Should that not be __fwriting instead of __fwritable ? Indeed. Thanks for the report. Fixed as part of this larger commit: 2020-10-11 Bruno Haible

Re: patch: stdio fiex for UnixWare

Tim Rice wrote in : > > I've attached a patch to address the fact that UnixWare does not have > stdio_ext.h but has some __X() stdio helper functions. > > Wrap "#include " in HAVE_STDIO_EXT_H insead of HAVE___X I'm applying

Re: HAMT iterators

Marc Nieper-Wißkirchen wrote: > For a bucket, in the worst case, we need the full size_t range for > position Right. I missed that. When the hash function is very bad (maps everything to a single hash code), the bucket is very large. Bruno

Re: HAMT for gl_set and gl_map

Hi Marc, > > How would a HAMT implementation look like that does not support persistence, > > but is instead optimized for destructive updates? Probably the reference > > counters would go away. Anything else? > > The reference counter would go away as would all tests for "shared" in the >

Re: Draft #3 (with iterators)

I have implemented everything we have discussed today. The patch versus the current master is attached so it can be reviewed. The changes versus the previous draft can be summarized as follows: * Bug fixes. * Use _Atomic on GCC 4.9+. * Implement a lightweight iterator type akin to the iterators

Re: stack bounds

On 10/10/20 2:49 PM, Bruno Haible wrote: gcc -fstack-clash-protection -m32 -O2 stackish.c fixes this issue. Yes. However, the GCC manual says this about -fstack-clash-protection: Most targets do not fully support stack clash protection. However, on those targets

Re: nap() name space clash

Hi Tim, > I've prepared 2 patch options for your consideration. > > The attached nap2gnulib_nap.patch renames nap to gnulib_nap and leaves > the tests/nap.h name alone. > > The attached nap2gnulib_nap_with_nap_h_rename.patch assumes a > "git mv tests/nap.h tests/gnulib_nap.h" It smells too

Re: another stdio patch for UnixWare

Hi Bruno, On Sun, 11 Oct 2020, Bruno Haible wrote: > Tim Rice wrote: > > ./gnulib-tool --create-testdir --dir=/var/tmp --with-tests \ > > --single-configure --avoid=havelib-tests fseterr freadable fwritable \ > > fbufmode freading fwriting freadptr freadseek freadahead fpurge fseeko >

Re: Draft #3 (with iterators)

Hi Marc, > I have implemented everything we have discussed today. The patch > versus the current master is attached so it can be reviewed. > > The changes versus the previous draft can be summarized as follows: > > * Bug fixes. > * Use _Atomic on GCC 4.9+. > * Implement a lightweight iterator

Re: Port getprogname module to SCO OpenServer

Hi Benji, > > It is better, but there are still (minor) things to tweak. > Minor things tweaked. > > I'm not sure why I cast getpid to int. > > Including string.h did fix the strrchr warning. > > Now using __SCO_SERVER__ || __sysv5__ for OpenServer6/UnixWare7 and SCO > cc/GCC detection.

Re: [New module] Persistent Hash Array Mapped Tries (HAMTs)

Am So., 11. Okt. 2020 um 10:20 Uhr schrieb Marc Nieper-Wißkirchen : > > Am So., 11. Okt. 2020 um 03:28 Uhr schrieb Bruno Haible : [...] > > * hamt_lookup: If the caller is allowed to modify the payload stored in the > > returned entry, this function should return a 'Hamt_entry *', not a > >

Re: patch: stdio fiex for UnixWare

Hi Bruno, On Sun, 11 Oct 2020, Bruno Haible wrote: > I'm applying the patch below, to fix this. The main differences to yours are: > * No need to touch the modules freadahead, freadptr, fseterr, since the > functions __freadahead, __freadptr, __fseterr don't exist on your > platform,

Re: terminology

Hi Marc, > I have attached an improved version of the HAMT module to this email. How about terminology: "delete" vs. "remove"? In C++ the verb "delete" is more or less the same as "free": It means "deallocate" and "free memory". Likewise in some C APIs, e.g. pthread_key_delete. In this sense,

Re: terminology

Am So., 11. Okt. 2020 um 16:14 Uhr schrieb Bruno Haible : > > Hi Marc, > > > I have attached an improved version of the HAMT module to this email. > > How about terminology: "delete" vs. "remove"? > In this sense, 'hamt_delete' is triggering the wrong associations. > How about renaming

Re: another stdio patch for UnixWare

Tim Rice wrote: > 2020-09-30 Tim Rice > * lib/stdio-impl.h: Add support for UnixWare I prefer to use the ifdefs that we found a couple of days ago. What did you mean by "best not to use __base on these platforms", when 4 lines below, the code does # define _base __base

Re: another stdio patch for UnixWare

Tim Rice wrote: > * lib/fflush.c: Update comments for UnixWare > * lib/fpending.c: Likewise. > * lib/freadable.c: Likewise. > * lib/freadptr.c: Likewise. > * lib/freadseek.c: Likewise. > * lib/fseterr.c: Likewise. > * lib/fwritable.c:

Re: another stdio patch for UnixWare

Tim Rice wrote: > ./gnulib-tool --create-testdir --dir=/var/tmp --with-tests \ > --single-configure --avoid=havelib-tests fseterr freadable fwritable \ > fbufmode freading fwriting freadptr freadseek freadahead fpurge fseeko > ftello fpending fflush Yes, this is the way to test these