Re: gl_list API

[Bruno Haible]

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 with this. When you write a list type for use within
a particular program, you can say "storing null elements is not useful".
But when designing a general utility, for all kinds of programs to use,
it is inappropriate to say "storing null elements is not useful". The
program's developer decides about the representation of their data, and
if they find that NULL is a perfect representation for something, then
that's their valid choice.

> If they really are needed for some 
> lists, I suppose one could have a more-complicated API to return them 
> (by setting a bool elsewhere); but usually they aren't.

I wanted to avoid this when designing the gl_list API: to have one
API for the case that disallows NULLs, and another — more complex — API
for that case that allows NULLs. One API function for one thing. No
redundancies.

> > The const typecast is, unfortunately, still needed to silence compiler
> > warnings
> 
> 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 pointer to a read-only storage
(such as a literal string) and receive a pointer that you "can" write
to: The compiler cannot warn about
   strchr ("literal", 'e') [2] = 'x';

> The API should discourage type-casts, since they're 
> more dangerous than the alternatives.

You can't write generic containers in C that don't need type-casts,
except by adding wrapper macros that do the type casts for the user.

So far we have been lacking type-casts that warn for invalid use;
it is well possible that with the PSPP macros (or with Marc's approach
of _Generic), we can design a type-safe wrapper around gl_list.h
that is parameterized by e.g.
  #define ELEMENT_TYPE  struct foo *
  #define LIST_TYPE     foo_list_t
  #define PREFIX        fl_
and that does warning-free but safe casts between 'struct foo *' and
'const void *'.

That's the direction we shoud go. Not backwards by using bad models
like strchr().

Bruno