[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gl_list API
From: |
Bruno Haible |
Subject: |
Re: gl_list API |
Date: |
Tue, 06 Apr 2021 22:28:59 +0200 |
User-agent: |
KMail/5.1.3 (Linux/4.4.0-206-generic; KDE/5.18.0; x86_64; ; ) |
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
- Type-safe typecasts, Marc Nieper-Wißkirchen, 2021/04/06
- Re: Type-safe typecasts, Paul Eggert, 2021/04/06
- Re: Type-safe typecasts, Marc Nieper-Wißkirchen, 2021/04/06
- Re: Type-safe typecasts, Paul Eggert, 2021/04/06
- Re: Type-safe typecasts, Marc Nieper-Wißkirchen, 2021/04/06
- Re: gl_list API,
Bruno Haible <=
- Re: gl_list API, Paul Eggert, 2021/04/06
- Re: gl_list API, Bruno Haible, 2021/04/06
- Re: gl_list API, Marc Nieper-Wißkirchen, 2021/04/06
- Re: cast macros, Bruno Haible, 2021/04/06
- Re: cast macros, Ben Pfaff, 2021/04/18
- Re: gl_list API, Ben Pfaff, 2021/04/18
- Re: Type-safe typecasts, Bruno Haible, 2021/04/06
Re: Type-safe typecasts, Ben Pfaff, 2021/04/06