On Tue, Apr 6, 2021 at 1:30 PM Bruno Haible wrote:
> Paul Eggert wrote:
> > Yes, that would be portable. But that cast indicates another problem
> > with the API. It should return void *, not void const * (think of strchr
> > as the model here).
>
> strchr is a bad model here: You pass it a pointe
Am Di., 6. Apr. 2021 um 23:04 Uhr schrieb Bruno Haible :
> > > But when designing a general utility, for all kinds of programs to use,
> > > it is inappropriate to say "storing null elements is not useful".
> >
> > I'm afraid we'll have to disagree here.
>
> In some of my uses of the gl_list modul
> > But when designing a general utility, for all kinds of programs to use,
> > it is inappropriate to say "storing null elements is not useful".
>
> I'm afraid we'll have to disagree here.
In some of my uses of the gl_list module, the element is in fact a small
integer, cast to an 'uintptr_t' an
On 4/6/21 1:28 PM, Bruno Haible wrote:
But when designing a general utility, for all kinds of programs to use,
it is inappropriate to say "storing null elements is not useful".
I'm afraid we'll have to disagree here. But then I don't use the API so
my comments aren't all that important.
Paul Eggert wrote:
> > gl_list_iterator_next has to return two things: An element (represented by
> > a const void *) and a boolean value. As elements may be NULL
>
> Ah, OK, then that's the problem. The API shouldn't allow null elements.
> They're not that useful anyway.
I disagree very much wi
