[vlc-devel] [PATCH 1/3] vlc_list: helpers for doubly linked lists

[Romain Vimont]

On Wed, Jun 13, 2018 at 10:46:09AM +0200, Romain Vimont wrote:
> On Wed, Jun 13, 2018 at 09:55:08AM +0300, Rémi Denis-Courmont wrote:
> > Err, it does not help. If I forego removal safety, I can remove it.next. I still need it.head for macro expansion safety (evaluate the head exactly once)
> 
> In think that head expansion-safety is not that important (in practice,
> the head is always passed "directly").
> 
> > and it.current to avoid undefined pointer arithmetic on empty list.
> 
> In the "unsafe-against-removal" version, I think it is possible to avoid
> UB (even if it's weird to return a void* to random memory). For example,
> the current unsafe version in the kernel does not trigger UB IMO.

Hmm, that's not true if &pos->member is UB when pos in invalid.

> 
> > 
> > So I still need the iterator.
> > 
> > Le 12 juin 2018 23:06:05 GMT+03:00, Romain Vimont <rom1v at videolabs.io> a écrit :
> > >On Tue, Jun 12, 2018 at 10:41:50PM +0300, Rémi Denis-Courmont wrote:
> > >> Le tiistaina 12. kesäkuuta 2018, 14.35.02 EEST Romain Vimont a écrit
> > >:
> > >> > Anyway, my remark about the safe/unsafe version was not about
> > >> > performance, but more about passing an additional argument that
> > >could be
> > >> > avoided in most cases (a foreach with 5 arguments is quite complex
> > >to
> > >> > use).
> > >> 
> > >> Third and fifth arguments define what is actually iterated, and seem 
> > >> intrinsically necessary. The first argument defines a variable name
> > >and is 
> > >> necessary to avoid shadowing.
> > >
> > >Yes.
> > >
> > >> I cannot find a way to avoid the second (iterator) argument without
> > >both 
> > >> relying on UB and losing safety against element removal.
> > >
> > >I agree. But I think that it is very common to iterate over a list
> > >without removing, so providing an additional macro with one parameter
> > >less (and one variable declaration less "struct vlc_list_it it;" for
> > >each caller) could be worth it.
> > >
> > >> The forth argument can be avoided with typeof, but I cannot see a
> > >well-defined 
> > >> and standard-compliant alternative. Specifically
> > >>     (((char *)(&pos->member)) - ((char *)pos))
> > >> is constant but undefined if pos is not initialized or not a valid
> > >pointer. As 
> > >> far as I recall, ubsan is prone to tripping on it.
> > >
> > >I cannot see a well-defined+standard-compliant solution either.
> > >
> > >However, it seems that every modern compiler supports typeof() or
> > >__typeof() or __typeof__():
> > >
> > ><https://stackoverflow.com/a/14878370/1987178>
> > >
> > >Maybe we could #define some vlc_typeof() to use the right name?
> > >_______________________________________________
> > >vlc-devel mailing list
> > >To unsubscribe or modify your subscription options:
> > >https://mailman.videolan.org/listinfo/vlc-devel
> > 
> > -- 
> > Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
> 
> > _______________________________________________
> > vlc-devel mailing list
> > To unsubscribe or modify your subscription options:
> > https://mailman.videolan.org/listinfo/vlc-devel
> 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel