[PATCH weston 2/3] ivi-shell: clear order.layer_list before reordering it

Pekka Paalanen ppaalanen at gmail.com
Fri Aug 21 01:26:01 PDT 2015


On Thu, 20 Aug 2015 11:52:47 -0700
Bill Spitzak <spitzak at gmail.com> wrote:

> On Thu, Aug 20, 2015 at 7:13 AM, Ucan, Emre (ADITG/SW1) <
> eucan at de.adit-jv.com> wrote:
> 
> >
> > Checking wl_list_empty() on a link offers no information: if it returns
> > true, wl_list_remove() is safe to do. If it returns false, you still do not
> > know if wl_list_remove() is safe;
> > the link could be part of a list, or the link could be "uninitialized"
> > (e.g. just wl_list_remove()'d). (From Pekka Paalanen's comment at
> > http://lists.freedesktop.org/archives/wayland-devel/2015-August/023987.html
> > ).
> >
> 
> Correct me if I am wrong, but I think a more accurate statement is "if
> wl_list_remove() is going to crash, then wl_list_empty() is also going to
> crash. Therefore there is no reason to test wl_list_empty()". (by "crash" I
> mean "use an uninitialized pointer" but that is the usual result).

No, wl_list_empty() will not crash, if the given wl_list pointer is
good but the prev or next members of it are not. wl_list_empty() does
not dereference prev or next, but wl_list_remove() does.

Also quite often with broken lists, dereferencing the broken prev or
next pointers does not result in a crash. These pointers point to
memory that was valid, is valid, or can even be the expected data
structure (the most common case). Often the only indication of list
corruption is list traversal going into an infinite loop. This can
happen without any invalid memory accesses (that is, access to freed or
never allocated memory or NULL).

Incorrect list operations do not necessarily imply invalid memory
access.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20150821/300472bb/attachment.sig>


More information about the wayland-devel mailing list