<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">Le 25 juil. 2017 19:45, "Rémi Denis-Courmont" <<a href="mailto:remi@remlab.net">remi@remlab.net</a>> a écrit :<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text">Le tiistaina 25. heinäkuuta 2017, 19.22.19 EEST Steve Lhomme a écrit :<br>
> On Tue, Jul 25, 2017 at 6:33 PM, Rémi Denis-Courmont <<a href="mailto:remi@remlab.net">remi@remlab.net</a>><br>
wrote:<br>
> > Le tiistaina 25. heinäkuuta 2017, 18.06.32 EEST Steve Lhomme a écrit :<br>
> >> So that's it coherent with the rest of the usages.<br>
> ><br>
> > Not really. The other uses operate on an initialized object. Here, we are<br>
> > creating and initializing the object.<br>
><br>
> It's just about accessing the pointer.<br>
<br>
</div>Says who? I wrote those accessor macros, and that´s not how I conceived them<br>
nor how I think of them. Using accessors on unitialized objects makes no sense<br>
to me.</blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Insisting on having distinct ways to access the same thing is what doesn't make sense to me. But if you do insist then add a static assert to ensure when you compile that your advanced pointer tricks actually match in both cases. </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text">
> It doesn't matter what is in the pointed data.<br>
<br>
</div>The current implementation of the macros is such that initialization does not<br>
matter. Likewise, it is such that this patch does not matter; it replaces one<br>
expression with an equivalent expression.<br>
<br>
So nack.<br>
<div class="quoted-text"><br>
> > flexible array in ISO C ensures that the two expressions are equivalent.<br>
> > One uses byte offsets, and the other direct pointer arithmetic.<br>
><br>
> If that was equivalent, this wouldn't fail:<br>
> static_assert( sizeof(struct vlc_object_internals) !=<br>
>              offsetof(struct vlc_object_internals, aligned_end),<br>
>              "invalid align_end access");<br>
<br>
</div>It *is* equivalent, and that assertion *cannot* fail.<br>
<br>
By definition of pointer arithmetic, pointer plus one equals the pointer plus<br>
the size of pointed type and by definition of flexible arrays, the offset of a<br>
flexible array within its contained structure is the size of the structure.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Can you point to doc about that because I couldn't understand how it works in the regular case (and it does). Because my understanding of container_of is that it gives the starting offset of the field in the structure. Except in this case it's the end of the structure. </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That was the whole point of appending aligned_end in the first place.<br>
<div class="elided-text"><br>
--<br>
雷米‧德尼-库尔蒙<br>
<a href="https://www.remlab.net/" rel="noreferrer" target="_blank">https://www.remlab.net/</a><br>
<br>
______________________________<wbr>_________________<br>
vlc-devel mailing list<br>
To unsubscribe or modify your subscription options:<br>
<a href="https://mailman.videolan.org/listinfo/vlc-devel" rel="noreferrer" target="_blank">https://mailman.videolan.org/<wbr>listinfo/vlc-devel</a></div></blockquote></div><br></div></div></div>