Thank you, Paul. My local tests also show that it behaves better now.
Am Mi., 5. Jan. 2022 um 20:54 Uhr schrieb Paul Eggert :
>
> On 1/5/22 10:00, Bruno Haible wrote:
> > Another possible fix would be to change
> >size_t size;
> > to
> >idx_t size;
> > in the struct.
>
> Yes, that fits bet
On 1/5/22 10:00, Bruno Haible wrote:
Another possible fix would be to change
size_t size;
to
idx_t size;
in the struct.
Yes, that fits better into our strategy of preferring signed to unsigned
types for sizes. Plus, it avoids a cast that's too powerful in C. I
installed the attached.Fro
Marc Nieper-Wißkirchen:
> If "stack.h" is included by client code that is supposed to be
> compiled with "-Wsign-compare", the compiler will complain about the
> comparison on line 121.
Indeed: although we don't care about -Wsign-compare warnings in Gnulib
code, consumers of .h files from Gnulib m
Commit 3dc36216f168f4e752b648b19d85eab32a037827 by Paul Eggert
introduced a regression in the stack module.
If "stack.h" is included by client code that is supposed to be
compiled with "-Wsign-compare", the compiler will complain about the
comparison on line 121.
There was
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 (&stack);
>
> I
Hi Marc,
> please see the attached patch for the new module.
Very nice. Looks all good, except for some nit-picking in the comments:
> + Introspection: ELEMENT *base = stack_base (&stack);
I would add a comment here:
Where ELEMENT is the type to which GL_STACK_ELEMENT was defined whe
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 schrieb Bruno Haible :
&g
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.
>
&g
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 omit
Hi Marc,
> The alternative with the same type safety would be a source file with
> stack code procedures meant for inclusion (without include guards).
> The source file would expect a preprocessor defines GL_STACK_NAME,
> GL_STACK_TYPE, and GL_STACK_EXTERN.
>
> The file itself would contain code
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 type safety. The benefit of the current approach is that
> > stack types of differe
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 t
Paul Eggert wrote:
> I don't want to encourage programmers to supply an E with side effects, as
> side
> effects are trouble here.
+1
On 5/24/20 1:17 AM, Marc Nieper-Wißkirchen wrote:
> 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.
We can *make* it true, by fiat. :-)
I don't want to encourage programme
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 Uh
On 5/23/20 3:06 PM, Bruno Haible wrote:
> How about this instead?
Thanks, good point about the danger. Also, I forgot to include verify.h.
I tightened up the commentary, folded in Marc's suggestion, and installed the
attached.
>From 2df56dc44200074077ebace04079ac4b0a34e4fc Mon Sep 17 00:00:00 200
Hi Paul,
> Something like the attached?
This documentation is quite misleading:
+/* Check E's value at runtime, and report an error and abort if not.
+ However, do nothing if NDEBUG is defined; in this case behavior is
because the "do nothing" is an understatement. 'assume' is a dangerous
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.
>
> Something like the attached?
That would be a
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.
Something like the attached?
diff --git a/lib/assure.h b/lib/assure.h
index 8ea2f6e48..2f1326027 100644
--- a/lib
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 "verify.h
On 5/23/20 9:54 AM, Marc Nieper-Wißkirchen wrote:
> Sure, but not in "-O0" or "-Og" builds, I think. Or am I mistaken?
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.
Marc Nieper-Wißkirchen wrote:
> > 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.
Indeed. Yes, it's a difficult trade-off between
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 compiler is entitled to optimize away
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 compiler is entitled to optimize away the 'assure (X)' in this
case. I installed the attached to try to e
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.
>
> I wouldn't call 'assume (X)' a "r
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.
I wouldn't call 'assume (X)' a "runtime check". It's more an anti-runtime-check.
'assume (X)' is a di
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 S
Hi Marc,
> > 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 cod
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 poss
Hi Marc,
> Alternatively, one could implement a universally usable stack through
> the following header file (mimicking somewhat C++ templates). What do
> you think? It will be a lot faster than using the general list modules
> of Gnulib.
I agree that a generic 'stack' mo
30 matches
Mail list logo
