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