Issue in src/xfns.c

Issue in src/xfns.c

[Christian Lynbech]

I am not entirely sure what the intention was, but I think there is a
small issue in xfns.c in relation to the RANDR13_LIBRARY macro.

It is used in two places, one where it uses #if and another that uses
#ifdef, the latter of which I think should have been a #if. At least it
failed to compile for me on a rather old linux system with a setup I
know onbly a little about. The define that introduces RANDR13_LIBRARY is
a boolean expression so RANDR13_LIBRARY is always defined.

As far as I can see this is still present in the git repository on the
master branch. An attempt of a patch is given below.


Index: xfns.c
===================================================================
--- xfns.c              (revision 7708)
+++ xfns.c           (working copy)
@@ -4286,7 +4286,7 @@
   n_monitors = resources->noutput;
   monitors = xzalloc (n_monitors * sizeof *monitors);
-#ifdef RANDR13_LIBRARY
+#if RANDR13_LIBRARY
   if (randr13_avail)
     pxid = XRRGetOutputPrimary (dpy, dpyinfo->root_window);
#endif


------------------------+-----------------------------------------------------
Christian Lynbech       | christian #\@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
                                        - petonic@hal.com (Michael A. Petonic)

Re: Issue in src/xfns.c

[Ken Raeburn]

> On Jun 14, 2016, at 14:02, Christian Lynbech <christian@defun.dk> wrote:
> 
> 
> I am not entirely sure what the intention was, but I think there is a
> small issue in xfns.c in relation to the RANDR13_LIBRARY macro.
> 
> It is used in two places, one where it uses #if and another that uses
> #ifdef, the latter of which I think should have been a #if. At least it
> failed to compile for me on a rather old linux system with a setup I
> know onbly a little about. The define that introduces RANDR13_LIBRARY is
> a boolean expression so RANDR13_LIBRARY is always defined.
> 
> As far as I can see this is still present in the git repository on the
> master branch. An attempt of a patch is given below.

Yes, this is a silly bug in my patch from March, present in both master and emacs-25. Unfortunately the user’s environment that I made the patch for had older xrandr support in the server but newer libraries (on different machines, if I recall correctly), so it slipped through testing. :-(

Christian’s patch is straightforward and looks correct to me. It should take a system with an older (pre-1.3) xrandr library to cause compilation to fail, and I don’t have such a system to test on.

John, you’re steering the ship again now, right? (I hope you had a great vacation!) Most modern X installations shouldn’t be affected by this, but as Christian shows, there’ll probably be a few outdated ones that’ll be affected. Okay to commit this fix for emacs-25?

Ken

Re: Issue in src/xfns.c

[John Wiegley]

[-- Attachment #1: Type: text/plain, Size: 666 bytes --]

>>>>> Ken Raeburn <raeburn@raeburn.org> writes:

> John, you’re steering the ship again now, right? (I hope you had a great
> vacation!) Most modern X installations shouldn’t be affected by this, but as
> Christian shows, there’ll probably be a few outdated ones that’ll be
> affected. Okay to commit this fix for emacs-25?

If most modern X installations aren't affected, then it can wait until 25.2.
We are in the final stretch for 25.1, so unless it's worth blocking the
release, it waits.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

Re: Issue in src/xfns.c

[Paul Eggert]

John Wiegley wrote:
> If most modern X installations aren't affected, then it can wait until 25.2.

OK, I installed it in master.