<div dir="ltr">On one hand it may be dangerous for the scenario that you've described, but on the other hand why are you (or anyone) needing to call internal, non-exported libwayland functions?<div><br></div><div>??</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Oct 19, 2017 at 3:11 AM Boram Park <<a href="mailto:boram1288.park@samsung.com">boram1288.park@samsung.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 2017년 09월 28일 00:13, Derek Foreman wrote:<br>
> On 2017-09-26 10:46 AM, Sergi Granell wrote:<br>
>> On Thu, 2017-09-14 at 09:21 +0900, Boram Park wrote:<br>
>>> Before putting data into a buffer, we have to make sure that the data<br>
>>> size is<br>
>>> smaller than not only the buffer's full size but also the buffer's<br>
>>> empty<br>
>>> size.<br>
>>><br>
>>> <a href="https://bugs.freedesktop.org/show_bug.cgi?id=102690" rel="noreferrer" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=102690</a><br>
>>><br>
>>> Signed-off-by: Boram Park <<a href="mailto:boram1288.park@samsung.com" target="_blank">boram1288.park@samsung.com</a>><br>
>>> Acked-by: Pekka Paalanen <<a href="mailto:pekka.paalanen@collabora.co.uk" target="_blank">pekka.paalanen@collabora.co.uk</a>><br>
>>> ---<br>
>>>   src/connection.c | 9 ++++++---<br>
>>>   1 file changed, 6 insertions(+), 3 deletions(-)<br>
>>><br>
>>> diff --git a/src/connection.c b/src/connection.c<br>
>>> index 5c3d187..53b1621 100644<br>
>>> --- a/src/connection.c<br>
>>> +++ b/src/connection.c<br>
>>> @@ -63,14 +63,17 @@ struct wl_connection {<br>
>>>       int want_flush;<br>
>>>   };<br>
>>>   +static uint32_t wl_buffer_size(struct wl_buffer *b);<br>
>>> +<br>
>><br>
>> I think it would be a better idea to move the wl_buffer_size definition<br>
>> at the top to avoid this forward declaration.<br>
>><br>
>>>   static int<br>
>>>   wl_buffer_put(struct wl_buffer *b, const void *data, size_t count)<br>
>>>   {<br>
>>> -    uint32_t head, size;<br>
>>> +    uint32_t head, size, empty;<br>
>>>   -    if (count > sizeof(b->data)) {<br>
>>> +    empty = sizeof(b->data) - wl_buffer_size(b);<br>
>>> +    if (count > empty) {<br>
>>>           wl_log("Data too big for buffer (%d > %d).\n",<br>
>>> -               count, sizeof(b->data));<br>
>>> +               count, empty);<br>
>>>           errno = E2BIG;<br>
>>>           return -1;<br>
>>>       }<br>
><br>
> I'm not sure I like this.  I've looked and all callers should already<br>
> have this check - are you actually getting here with this condition<br>
> somehow?<br>
looks it will never happen because all callers already check the data<br>
size before putting.<br>
> Also, the patch changes the meaning of E2BIG from the caller's<br>
> perspective (if we can even get here), doesn't it? Previously E2BIG<br>
> meant the packet could never fit, now it would mean that the packet<br>
> can't fit now.<br>
><br>
> I think maybe just a comment mentioning that all the callers must<br>
> ensure the data will fit could be enough?<br>
However, it looks really dangerous for someone who don't know above rule<br>
that caller should check the buffer empty size before calling wl_buffer_put.<br>
comment might be helpful to understand the intention of developer who<br>
implemented this code.<br>
But the sanity check is much better to ensure safety, I think.<br>
<br>
><br>
> I could even see an assert(), since this is a conditional that should<br>
> never fire.<br>
><br>
> But I really don't like changing the meaning of the error code.<br>
><br>
> Thanks,<br>
> Derek<br>
><br>
>> Other than that,<br>
>><br>
>> Reviewed-by: Sergi Granell <xerpi.g.12 at <a href="http://gmail.com" rel="noreferrer" target="_blank">gmail.com</a>><br>
>> _______________________________________________<br>
>> wayland-devel mailing list<br>
>> <a href="mailto:wayland-devel@lists.freedesktop.org" target="_blank">wayland-devel@lists.freedesktop.org</a><br>
>> <a href="https://lists.freedesktop.org/mailman/listinfo/wayland-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
>><br>
><br>
> _______________________________________________<br>
> wayland-devel mailing list<br>
> <a href="mailto:wayland-devel@lists.freedesktop.org" target="_blank">wayland-devel@lists.freedesktop.org</a><br>
> <a href="https://lists.freedesktop.org/mailman/listinfo/wayland-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
<br>
_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org" target="_blank">wayland-devel@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/wayland-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
</blockquote></div>