[PATCH wayland] client: Allow absolute paths in WAYLAND_DISPLAY

[Pekka Paalanen]

On Fri, 10 Nov 2017 11:19:49 -0600
Matt Hoosier <matt.hoosier at gmail.com> wrote:

> Hi,
> 
> On Fri, Nov 10, 2017 at 5:37 AM, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> > On Thu,  9 Nov 2017 09:36:29 -0600
> > Matt Hoosier <matt.hoosier at gmail.com> wrote:
> >  
> >> From: Matt Hoosier <matt.hoosier at garmin.com>
> >>
> >> In order to support system compositor instances, it is necessary to
> >> allow clients' wl_display_connect() to find the compositor's listening
> >> socket somewhere outside of XDG_RUNTIME_DIR. For a full account, see
> >> the discussion beginning here:
> >>
> >> https://lists.freedesktop.org/archives/wayland-devel/2017-November/035664.html
> >>
> >> This change adjusts the client-side connection logic so that, if
> >> WAYLAND_DISPLAY is formatted as an absolute pathname, the socket
> >> connection attempt is made to just $WAYLAND_DISPLAY rather than
> >> usual user-private location $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY.
> >>
> >> This change is based on Davide Bettio's submission of the same concept
> >> at:
> >>
> >> https://lists.freedesktop.org/archives/wayland-devel/2015-August/023838.html.  

> >>  doc/man/wl_display_connect.xml | 11 ++++++++---
> >>  src/wayland-client.c           | 34 +++++++++++++++++++++++-----------
> >>  2 files changed, 31 insertions(+), 14 deletions(-)

> > One more thing to make this change perfect would be to add a test in
> > the test suite to check that an absolute path works. It could live in
> > socket-test.c maybe.  
> 
> Writing the actual test wasn't very hard. But I ran aground on the
> memory-leak checker. There are implicit allocations done by setenv()
> calls in the individual test case to set $WAYLAND_DISPLAY to hold the
> absolute path needed by the impending call to wl_display_connect(). I
> couldn't find any guaranteed way to reclaim that memory -- unsetenv()
> doesn't do the job.
> 
> If you have any thoughts on ways to get around this, I can add the test in.

Hi Matt,

I believe we just have to let that leak then. Looks like we have
DISABLE_LEAK_CHECKS macro which you could use with a comment pointing
to setenv.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20171114/885da696/attachment.sig>