Hi Bruno,
Hi Reuben,
>/The test for whether to use valgrind runs:/
>//
>//bin/bash -c 'exit 0'/
>//
>/This looks pretty harmless; unfortunately, bash itself causes problems:/
I'd suggest that you change m4/valgrind-tests.m4 to use the AC_CACHE_CHECK
macro instead
In freea in malloca.c, a possibly uninitialized indicator word is used for
a comparison so that Valgrind reports: "Conditional jump or move depends on
uninitialised value(s)".
Valgrind is not smart enough to understand the logic in freea.
It would be nice if the warning could be silenced, either
I just noticed the file lib/malloca.valgrind, which can be used with the
Valgrind option suppressions.
Marc
Am 22.08.2017 5:52 nachm. schrieb "Tim Rühsen" <tim.rueh...@gmx.de>:
> On Dienstag, 22. August 2017 06:11:41 CEST Marc Nieper-Wißkirchen wrote:
> > In freea
Universally unique identifiers (UUIDs) are needed in various application
scenarios. It would be quite helpful if Gnulib included a module with a
UUID generator. As Gnulib already contains (strong) random number
generators, implementing such a UUID generator shouldn't be too hard.
Linux systems
Dear all,
I'm working on a shared library, for which implementation I make use of
gnulib modules.
I followed the instructions for the lib-symbol-visibility module (see here:
https://www.gnu.org/software/gnulib/manual/html_node/Exported-Symbols-of-Shared-Libraries.html)
to make only the
Paul Eggert schrieb am Mi., 29. Apr. 2020, 18:01:
> On 4/29/20 7:28 AM, Marc Nieper-Wißkirchen wrote:
> > I am wondering whether it makes sense to add two new modules, named
> > pure and const that define macros GL_PURE and GL_CONST, respectively
>
> There's alrea
Some GNULIB modules (e.g. xsize) use constructs like:
#if __GNUC__ >= 3
__attribute__ ((__pure__))
#endif
I am wondering whether it makes sense to add two new modules, named
pure and const that define macros GL_PURE and GL_CONST, respectively
that expand into nothing for a compiler that does not
The flexmember module provides the macro FLEXSIZEOF to calculate an
appropriate size to malloc a struct with a flexible array member.
Overflow is reported differently than with the xsize module, which
provides size_overflow_p.
It would be great if the flexmember exported another macro, say
Am Do., 30. Apr. 2020 um 22:54 Uhr schrieb Paul Eggert :
>
> On 4/30/20 6:08 AM, Bruno Haible wrote:
> > These not-so-new compilers don't perform
> > character set conversion; you have to provide the numeric value of each
> > byte yourself (either as escapes, or by enumerating the bytes of the
> >
Am Fr., 1. Mai 2020 um 02:46 Uhr schrieb Paul Eggert :
>
> On 4/30/20 6:37 AM, Marc Nieper-Wißkirchen wrote:
> > P.S.: It would also be helpful so that warnings coming from
> > "-Wsuggest-attribute=pure" can be handled for the GCC without
> > affecting other
Am Fr., 1. Mai 2020 um 00:20 Uhr schrieb Paul Eggert :
>
> On 4/30/20 2:01 PM, Marc Nieper-Wißkirchen wrote:
>
> >>>> #define XFLEXSIZEOF_XSIZE(type, member, n) \
> >>>> (((n) <= FLEXSIZEOF (type, member, n) \
> >>>> && F
Am Fr., 1. Mai 2020 um 11:09 Uhr schrieb Bruno Haible :
>
> Paul Eggert wrote:
> > I realize we have dueling conventions here, but would prefer that
> > saturated size_t arithmetic have a longer prefix or suffix than just "x".
>
> I'm open to this. What prefix would you propose instead of 'x'?
Am Mi., 29. Apr. 2020 um 18:05 Uhr schrieb Marc Nieper-Wißkirchen
:
>
>
> Paul Eggert schrieb am Mi., 29. Apr. 2020, 18:01:
>>
>> On 4/29/20 7:28 AM, Marc Nieper-Wißkirchen wrote:
>> > I am wondering whether it makes sense to add two new modules, named
>>
Hi Bruno,
thanks again very much!
Am Sa., 2. Mai 2020 um 02:07 Uhr schrieb Bruno Haible :
>
> Marc Nieper-Wißkirchen wrote:
> > This is a feature request to add an operation
> >
> > extern gl_list_node_t gl_list_remove_last (gl_list_t list)
> >
&
Hi Bruno,
[...]
> The gl_list_node_t type, in the 'list' interface so far, is used in
> operations that work on a single position. Except for the functions
> gl_list_next_node and gl_list_previous_node, which intentionally
> walk from one node to a neighbour node. Having a function that
> does
Hi Bruno,
[...]
> > I don't see, however, to implement the function dealing with
> > end of the list in O(1) behavior when the underlying data structure is
> > a linked list.
>
> The LINKED list implementation is a doubly-linked list, and the functions
> get_at, set_at, or remove_at are
Hi Bruno,
excellent; thank you very much!
Just one note: The documentation needs to be updated in section 14.8
as well ([1]).
So long,
Marc
[1] https://www.gnu.org/software/gnulib/manual/gnulib.html#Container-data-types
Am Sa., 2. Mai 2020 um 23:24 Uhr schrieb Bruno Haible :
>
> I wrote:
> >
Hi Paul,
thank you very much.
If I understand correctly, the patch seems to cover compilers that
declare "__has_attribute", which should cover GCC and Clang. Does it
make sense to support MSC's "__declspec" as well?
As for the future-proof C2X approach: In the GCC 10 Changes
This is a feature request to add an operation
extern gl_list_node_t gl_list_remove_last (gl_list_t list)
to the list/xlist interface.
This operation would remove the last element of the list and return
the node of the previous element (or NULL if no element remained).
There are at least two
Thank you very much for your quick response!
Am Do., 30. Apr. 2020 um 00:39 Uhr schrieb Paul Eggert :
>
> On 4/29/20 12:29 PM, Marc Nieper-Wißkirchen wrote:
> > It would be great if the flexmember exported another macro, say
> > XFLEXSIZEOF, which returned SIZE_MAX in case of a
On a system that supports at least C11, I can create an UTF8-encoded
literal string through:
(uint8_t const *) u8"..."
Could Gnulib abstract this into a macro so that substitutes for
systems that do not have u8 string literals can be provided.
On a C11 system, we would have
#define UTF8(s)
Hi Bruno,
thank you very much for your reply.
Am Do., 30. Apr. 2020 um 12:06 Uhr schrieb Bruno Haible :
[...]
> Unfortunately, we cannot provide such macros. The reason is that the
> translation from the source file's encoding to UTF-8/UTF-16/UTF-32 must
> be done by the compiler, if you want
Thank you, both of you!
Have a nice weekend,
Marc
Am Fr., 15. Mai 2020 um 23:04 Uhr schrieb Bruno Haible :
>
> Hi Paul,
>
> > I don't think we need to go that far, since c-stack is already using
> > ignore_value. I installed the attached.
>
> You beat me to it by 2 minutes :)
>
> I verified
It is often important to be able to read back a written floating-point
number accurately so it has to be output with high enough precision.
The Scheme standard even demands this for the number->string and
string->number procedures. Moreover, for output, the shortest rounded
representation that
r the suggestion. Done.
>
>
> 2020-05-09 Bruno Haible
>
> c-stack: Fix warning when DEBUG is enabled.
> Patch suggested by Marc Nieper-Wißkirchen
> in
> <https://lists.gnu.org/archive/html/bug-gnulib/2020-05/msg00081.html>.
> * lib
Please add
#ifdef DEBUG
# include
#endif
at the beginning of c-stack.c.
When the DEBUG flag is enabled, c-stack.c uses sprintf and without the
suggested addition gcc complains about an implicit declaration of the
function sprintf.
Thanks,
Marc
Please see the attached patch file, my first attempt (and first
contribution to Gnulib).
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_d
Am Di., 19. Mai 2020 um 09:44 Uhr schrieb Marc Nieper-Wißkirchen
:
> Such input and output routines for floats and doubles would also be
> very helpful in the C language. Do you think this could become a
> Gnulib module?
I have just discovered the "dtoastr" module, which seem
Am Di., 19. Mai 2020 um 17:10 Uhr schrieb Marc Nieper-Wißkirchen
:
> I have just discovered the "dtoastr" module, which seems to do what I
> want. It is, however, locale-dependent, and there is no "c_dtoastr"
> version as there is a "c_strtod". (Coul
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?)
> &
ftoastr.h tests for _GL_FTOASTR_H, but does not define it.
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 transferring the "Nutzungsrecht" is enough, everything should be fine.
Marc
Hi Bruno,
[...]
> The only (tiny) issue is a matter of style: Two of the new module files don't
> end in a newline. In Gnulib, we try to let every non-empty text file end in a
> newline, since "cat FILE" and "sed -e ... FILE" work better this way.
I will correct this when I send you the final
Hi Bruno,
> In Gnulib, we usually avoid extensive use of multi-line macros, because
> it hampers debuggability. Here, however, one needs macros, in order to
> accommodate the TYPE argument, which is not necessarily compatible to 'void
> *'.
> Nevertheless, we would try to put as much code as
Am Sa., 23. Mai 2020 um 16:52 Uhr schrieb Bruno Haible :
> > In a future version, I may add a flag to select between %e, %f, and %g.
>
> Hmm, that route is likely going the path to sprintf: First a flag to
> select among %e, %f, %g. Then an optional width. Then a flag to select
> whether to fill
Am Sa., 23. Mai 2020 um 16:02 Uhr schrieb Bruno Haible :
> I was expecting that you write
>
> struct
> {
> void *base; ...
> }
This removes type safety. The benefit of the current approach is that
stack types of different types are not compatible.
> Then macro should better be called
Am Sa., 23. Mai 2020 um 18:44 Uhr schrieb Paul Eggert :
>
> On 5/23/20 8:55 AM, Marc Nieper-Wißkirchen wrote:
> > A combination of assure and assume would be helpful:
> >
> > #define checked_assume(X) do { assure (X); assume (X); } while (0)
>
> No, because the co
Am Sa., 23. Mai 2020 um 17:39 Uhr schrieb Paul Eggert :
>
> On 5/23/20 7:36 AM, Marc Nieper-Wißkirchen wrote:
> > The verify also contains a runtime check `assume', which uses
> > __builtin_unreachable if available to help the compiler in optimizing
> > modes.
>
&
Thank you very much, Paul!
One bit of the commentary is still misleading, though, I think. You
wrote for the affirm macro that if NDEBUG is defined that the behavior
is undefined if E has side effects. That's not true as long as E does
not evaluate to false.
Marc
Am So., 24. Mai 2020 um 04:14
When an application bundles Gnulib tests in its distribution, say in a
folder named gnulib-tests, and has its own suite of Automake tests in the
folder tests, the console output by Automake when running
make check
is suboptimal because it will print something like
Hi Bruno,
Am Sa., 2. Mai 2020 um 17:49 Uhr schrieb Bruno Haible :
>
> Hi Marc,
>
> > Okay; I agree that a separate stack or FIFO module can make more
> > sense; in particular when it only has to deal with a single
> > implementation of an underlying data structure. At the moment I do
> > have
Hi Paul,
Am Sa., 23. Mai 2020 um 19:33 Uhr schrieb Paul Eggert :
> Probably not for -O0. I'm not so sure for -Og. Either way, we shouldn't rely
> on
> GCC's current behavior in this area as it is neither documented nor guaranteed
> to stay the same.
Agreed.
> > #include
> > #include
Is there any built-in support in the valgrind-tests module for
suppression files? For example, if I want to run my tests under
valgrind (if available), I write
LOG_COMPILER = $(VALGRIND)
or, in case I use libtool,
LOG_COMPILER = $(LIBTOOL) --mode=execute $(VALGRIND)
But how to add valgrind
Am Sa., 23. Mai 2020 um 22:51 Uhr schrieb Paul Eggert :
>
> On 5/23/20 10:38 AM, Marc Nieper-Wißkirchen wrote:
> > But if "affirm" is fine with you, I would love to see it in a module.
> > Either in verify or assure or in a new module named affirm.
>
> Someth
C11 has introduced atomic types and atomic operations. When they are not
available, one can use locks/mutexes instead.
It would be nice if there was a Gnulib module that abstracts over this,
much like the threadlib module and friends abstract over a specific
threading implementation.
What I am
Am Di., 6. Okt. 2020 um 23:06 Uhr schrieb Bruno Haible :
> Marc Nieper-Wißkirchen wrote:
> > In file included from lib/gl_linked_list.c:29:
> > lib/gl_linked_list.c: In function 'gl_linked_iterator_from_to':
> > lib/gl_anylinked_list2.h:938:1: error: function might be candid
Dear Bruno,
please see the attached patch for the new module.
Thanks,
Marc
Am Mi., 7. Okt. 2020 um 11:01 Uhr schrieb Marc Nieper-Wißkirchen
:
>
> Hi Bruno,
>
> I am finally finishing my work on the stack module.
>
> Am Do., 23. Juli 2020 um 12:36 Uhr sc
Hi Bruno,
I am finally finishing my work on the stack module.
Am Do., 23. Juli 2020 um 12:36 Uhr schrieb Bruno Haible :
[...]
> This is perfectly acceptable for Gnulib. It has debuggability and type safety.
>
> You have precedent e.g. in lib/diffseq.h and lib/aligned-malloc.h.
>
> You can even
' if it is known to return normally
[-Werror=suggest-attribute=pure]
938 | gl_linked_iterator_from_to (gl_list_t list,
| ^~
Marc
Am Mo., 5. Okt. 2020 um 00:08 Uhr schrieb Bruno Haible :
>
> Hi Marc,
>
> Marc Nieper-Wißkirchen wrote:
> > Whe
When compiling Gnulib with -Wunused-parameter, I get the following
report from GCC:
lib/localename.c: In function 'gl_locale_name_thread_unsafe':
lib/localename.c:3117:57: error: unused parameter 'categoryname'
[-Werror=unused-parameter]
3117 | gl_locale_name_thread_unsafe (int category, const
One final issue (I hope):
At the moment, the header file exposes an opaque struct Hamt and
communication with the code happens through (stack-allocated) pointers
to a Hamt. In the implementation, however, each Hamt just consists of
two pointers (a pointer to a function table and a pointer to the
Okay, if you find the latter protocol better anyway, I will switch to
this protocol, and hamts will be stack-allocated (just two words) and
passed by value.
Thanks,
Marc
Am So., 18. Okt. 2020 um 19:58 Uhr schrieb Bruno Haible :
>
> Marc Nieper-Wißkirchen wrote:
> > The exist
+1,812 @@
+/* (Persistent) hash array mapped tries.
+ Copyright (C) 2020 Free Software Foundation, Inc.
+ Written by Marc Nieper-Wißkirchen , 2020.
+
+ This program is free software: you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published
ure" attribute so that
the code is compilable with -Werror -Wall -Wextra.
Am Sa., 10. Okt. 2020 um 15:50 Uhr schrieb Bruno Haible :
>
> Marc Nieper-Wißkirchen wrote:
> > > And a function that may invoke abort () does "affect observable state".
> >
> > This des
Am Sa., 10. Okt. 2020 um 16:54 Uhr schrieb Bruno Haible :
>
> Since you define GL_HAMT_THREAD_SAFE to either 0 or 1, you need
> to test it through
> #if GL_HAMT_THREAD_SAFE
> not
> #ifdef GL_HAMT_THREAD_SAFE
>
> Bruno
Oh, yes... thanks!
Am Sa., 10. Okt. 2020 um 16:39 Uhr schrieb Bruno Haible :
>
> Hi Marc,
>
> > I can ask for a better description of "pure" in the GCC manual.
>
> Yes, please.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97364
rstand _Atomic.
Am Sa., 10. Okt. 2020 um 17:01 Uhr schrieb Marc Nieper-Wißkirchen
:
>
> Am Sa., 10. Okt. 2020 um 16:54 Uhr schrieb Bruno Haible :
> >
> > Since you define GL_HAMT_THREAD_SAFE to either 0 or 1, you need
> > to test it through
> > #if GL_HAMT_THR
Hi Bruno,
Am Sa., 10. Okt. 2020 um 16:06 Uhr schrieb Bruno Haible :
>
> Hi Marc,
>
> > please see the attached patch for the new module.
>
> Very nice. Looks all good, except for some nit-picking in the comments:
Thanks.
>
> > + Introspection: ELEMENT *base = stack_base ();
>
> I would
Hi Bruno,
Am Sa., 10. Okt. 2020 um 16:35 Uhr schrieb Bruno Haible :
> It is exciting to see such a datastructure with various application domains
> [1]
> in Gnulib!
I'm glad that you like the idea.
>
> I haven't read through it line by line; nevertheless a couple of comments:
A few more
From: Marc Nieper-Wißkirchen
* MODULES.html.sh: Add entry for the stack module.
* modules/stack: New file.
* modules/stack-tests: New file.
* lib/stack.h: New file.
* tests/test-stack.c: New file.
---
ChangeLog | 9 +++
MODULES.html.sh | 1 +
lib/stack.h | 165
/srfi-146/srfi-146.html
Am Sa., 10. Okt. 2020 um 23:24 Uhr schrieb Marc Nieper-Wißkirchen
:
>
> Am Sa., 10. Okt. 2020 um 20:19 Uhr schrieb Paul Eggert :
>
> > #if __STDC_VERSION__ < 201112 || defined __STD_NO_ATOMICS__
> >
> > which is a cleaner way of writing
Am Sa., 10. Okt. 2020 um 19:41 Uhr schrieb Bruno Haible :
>
> Hi Marc,
>
> > Is there a special Gnulib way (or Autoconf macro) for the following test:
> >
> > #if defined (__STDC_VERSION__) && __STDC_VERSION__ >= 201112L &&
> > !defined (__STD_NO_ATOMICS__)
> >
> > I am asking because there may be
Am Sa., 10. Okt. 2020 um 20:19 Uhr schrieb Paul Eggert :
> #if __STDC_VERSION__ < 201112 || defined __STD_NO_ATOMICS__
>
> which is a cleaner way of writing the negative of the above test. These days
> there should be no reason to check whether __STDC_VERSION__ is defined,
> generally it's
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
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
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
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
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
,
Hamt_entry *const *elt_ptr);
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 :
> >- Creating a closure in C (unlike Scheme or Lisp) is tedious
>
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_iterato
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,
compilers.
* Implement purely non-pure hamts to replace ordinary hash tables.
* Add _nx versions of the procedures that won't call xalloc_die.
Many thanks to Bruno for his support, guidance and his great suggestions.
Marc
Am So., 11. Okt. 2020 um 19:32 Uhr schrieb Marc Nieper-Wißkirchen
:
>
>
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 re
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
Am So., 18. Okt. 2020 um 16:39 Uhr schrieb Bruno Haible :
>
> Hi Marc,
>
> > At the moment, the header file exposes an opaque struct Hamt and
> > communication with the code happens through (stack-allocated) pointers
> > to a Hamt. In the implementation, however, each Hamt just consists of
> > two
Hi Bruno,
thank you for your reply. I could finally track down the error. It was
in my build configuration. Somehow, the wrong "-I ..." flags were set
up during the compilation of the Gnulib modules. It's working now. So,
everything is alright with Gnulib and I can retract my bug report.
Please
PS It may also be due to a problem in my build system (I am using
non-recursive make) so that the system-wide locale.h is included and
not the Gnulib version...
Am Mi., 30. Sept. 2020 um 16:29 Uhr schrieb Marc Nieper-Wißkirchen
:
>
> It seems that I have stumbled across the same bug as re
Am Mi., 26. Aug. 2020 um 12:13 Uhr schrieb Bruno Haible :
> [CCing bug-gnulib and Marc Nieper-Wißkirchen.]
>
> Paul Eggert wrote in <https://bugs.gnu.org/42931>:
> > Bug#42931 prompted me to change the way
> > that the Gnulib diffseq module recurses so that the stack
It seems that I have stumbled across the same bug as reported here:
https://bugs.gentoo.org/709732
The compiler throws the following error at me:
lib/hard-locale.c: In function 'hard_locale':
lib/hard-locale.c:29:15: error: 'SETLOCALE_NULL_MAX' undeclared (first
use in this function); did you
Hi Bruno,
Am So., 24. Mai 2020 um 22:54 Uhr schrieb Bruno Haible :
> Yes, given that the platform support for these atomic types/operations is
> increasing, it would accelerate the adoption if there was a Gnulib module,
> like you describe it. Program developers could then adopt
> without
Hi Bruno,
Am Mo., 25. Mai 2020 um 09:24 Uhr schrieb Bruno Haible :
> Pools have the drawback that they add a configuration requirement on the
> application: What is the default size of the pool? When to increase the
> pool size? By how much? When to shrink the pool? The developer would have
>
Am Mi., 20. Mai 2020 um 00:15 Uhr schrieb Bruno Haible :
> Marc Nieper-Wißkirchen wrote:
> If the code you write is not related to your job, that is, if you are not
> being paid to write it, then the "Nutzungsrechte" belong to you - regardless
> whether your employment c
Am Mi., 20. Mai 2020 um 00:37 Uhr schrieb Bruno Haible :
> Marc Nieper-Wißkirchen wrote:
> > for output, the shortest rounded
> > representation that still reads back accurately has to be selected.
> > ...
> > A simple algorithm is given by Aubrey Jaff
So here is the updated stack module. The name "CLEAR" has been changed
to "DESTROY" as suggested by Bruno. Error checking has been included.
The macro interface remains. Although a macro interface means macros,
the macros are trivial and the type safety wins here, I think. I have
renamed
Am So., 31. Mai 2020 um 21:51 Uhr schrieb Bruno Haible :
> I'm not aware of a documented way to change this.
>
> Nevertheless, it is probably easy to do: When you look at the generated
> Makefile.in and search for the string 'summary for', you will see that
> it gets the text that follows it from
Thank you for your input. So I won't come up with a full-featured
(meta-programming) macro module but may propose one or the other small
module about macros that I have found useful (and fool-proof) in my
own code.
The amount of macro one needs depends on the programming style, of
course. For
> If you know of shortcomings of _GL_CONCAT, we need to determine whether we
> should just document a limitation, or spend the necessary macro complexity
> in order to fix it.
Sorry for the misunderstanding; _GL_CONCAT is fine because it takes a
detour over _GL_CONCAT0. But not every
Besides modules to improve system compatibility, Gnulib contains a
number of modules that provide "missing" functionality of the C
standard library (like the gl_list module).
What would be the chances to include a module with sophisticated
preprocessor macros like P99 ([1]) or the Boost
Hi Bruno,
thanks for catching that. The proposed change is perfect. Actually, I
had made that fix in my local code as well so I am wondering why it
didn't make itself into the patch I sent you.
Best,
Marc
Am Mo., 10. Aug. 2020 um 08:55 Uhr schrieb Bruno Haible :
>
> Hi Marc,
>
> On a
Hi,
a number of modules (like the hash module or the list module) allow
the user to specify callbacks (e.g. a comparison function).
Unfortunately, these procedures do not take a context parameter, which
can be a problem because C lacks closures.
The original qsort function in stdlib.h has the
Hi Bruno,
Am Fr., 10. Juli 2020 um 20:38 Uhr schrieb Bruno Haible :
> OK. Then let's take the problem seriously.
If your solution can be implemented portable, that will be the best
solution by far.
For GCC one can use nested functions, but how can
'partial_function_last' be implemented in ISO
Hi Bruno,
Am Do., 9. Juli 2020 um 22:16 Uhr schrieb Bruno Haible :
> > a number of modules (like the hash module or the list module) allow
> > the user to specify callbacks (e.g. a comparison function).
> > Unfortunately, these procedures do not take a context parameter, which
> > can be a
Hi Bruno,
thank you very much.
Best regards,
Marc
Am Do., 25. Juni 2020 um 21:19 Uhr schrieb Bruno Haible :
>
> > Marc Nieper-Wißkirchen wrote:
> > > Please see the attached patch file, my first attempt (and first
> > > contribution to Gnulib).
> >
Hi Bruno,
now that some operations together with their complexity for dealing
with the end of the list have been added, what do you think of adding
a reverse iterator?
Thanks,
Marc
PS I've received a reply by the FSF; now I am waiting for the response
by my university's lawyer.
Am Sa., 2. Mai
Am Mi., 3. Juni 2020 um 23:08 Uhr schrieb Bruno Haible :
> It's rarely used: In most cases, a list is either traversed one way or
> the other way.
One could say that a list that is to be transversed in both ways is a
different abstract data type; nevertheless, they appear (e.g. lists of
Am Fr., 24. Juli 2020 um 10:56 Uhr schrieb Florian Weimer :
> This is the case that is unclear:
>
> double x[2];
> double *p = [1];
>
> The standard explicitly says “first element of an array”.
That's fine as well, I think. "x + 1" just points to an array of
length 1 in memory.
Hi Bruno,
> This is perfectly acceptable for Gnulib. It has debuggability and type safety.
Perfect. Then I will come up with a module in this form.
> You have precedent e.g. in lib/diffseq.h and lib/aligned-malloc.h.
Good to know; I hadn't taken a look at these sources yet.
> You can even
Am Fr., 24. Juli 2020 um 10:05 Uhr schrieb Florian Weimer :
> It's still a candidate for an RFE. Martin Sebor has been working on
> such warnings. I'm going to talk to him.
It may also be useful for optimizations because the compiler may make
assumptions.
> >> It's also undefined when you
Am Sa., 23. Mai 2020 um 19:19 Uhr schrieb Bruno Haible :
>
> Marc Nieper-Wißkirchen wrote:
> > > I was expecting that you write
> > >
> > > struct
> > > {
> > > void *base; ...
> > > }
> >
> > This removes
Am Fr., 24. Juli 2020 um 08:53 Uhr schrieb Florian Weimer :
> * Bruno Haible:
> > (This is with gcc 10.1.0.)
> >
> > clang, OTOH, produces warnings for both foo1 and foo2.
> >
> > But I won't spend time to report a GCC bug on this, because - as you said -
> > without the ability to declare a
1 - 100 of 174 matches
Mail list logo
