It is better to create the values array once and not on every iteration..

Does not require two parameters. It could be replaced by
RegionDestroy() entirely but we leave it to have a match to
nxagentCreateRegion().

Now all cleanup code at the end of the function is gone so there's no
need for the gotos anymore. Just return directly.

move common code into helper function that also takes care of the ugly
alloc/free stuff.

Otherwise we will never be able to free the list because we do not know
if free() is allowed or not.

add else clauses, improve debugging, add comments

not a real memleak since it is followed by a FatalError...

The FIXME just described what the following function actually implements...

Attributes GH PR #922: https://github.com/ArcticaProject/nx-libs/pull/922

if neither NX_CLIENT ist provided nor /usr/NX/bin/nxclient is existing
try /usr/bin/nxdialog.

Currently the path is hardcoded.

Attributes GH PR #917: https://github.com/ArcticaProject/nx-libs/pull/917

The changes are either applied in the current version or the affected
file is no longer existing.

We have never built nxwin within this tree. And we never shipped
it. So drop the according logic.

We have also removed CYGWIN stuff in the past so nxwin probably would
not compile/work anyway...

Attributes GH PR #899: https://github.com/ArcticaProject/nx-libs/pull/899

We have no hardware that could blank the screen for us. So let
nxagentSaveScreen return False in some situations to let dix do the
default action.

we moved the auto-disconnect feature to an own timer so there's no
need for a special treatment in screen saver stuff anymore.

Option -timeout used the screensaver facility. This patch changes that
to an own timer that is independent. This effectly means we can drop
most of the derived screensaving stuff in a follow-up commit.

Attributes GH PR #895: https://github.com/ArcticaProject/nx-libs/pull/895

This was removed by mistake in 39866f5c.

Fixes ArcticaProject/nx-libs#904

Clean.c: In function ‘CleanZImage’:
Clean.c:141:23: warning: declaration of ‘j’ shadows a previous local [-Wshadow=local]
       register int i, j;
                       ^
Clean.c:88:16: note: shadowed declaration is here
   unsigned int j;
                ^
Clean.c: In function ‘CopyAndCleanImage’:
Clean.c:239:22: warning: declaration of ‘i’ shadows a previous local [-Wshadow=compatible-local]
         register int i;
                      ^
Clean.c:192:16: note: shadowed declaration is here
   register int i;
                ^
Clean.c:324:13: warning: declaration of ‘i’ shadows a previous local [-Wshadow=compatible-local]
         int i;
             ^
Clean.c:192:16: note: shadowed declaration is here
   register int i;
                ^

  commit 08d0481e299c28b64a0db9bb0782ba2b551028fd
  Author: Keith Packard <keithp@keithp.com>
  Date:   Sun Dec 15 01:12:22 2013 -0800

    os: Fix -Wshadow errors

    Rename variables to avoid shadowing globals
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Eric Anholt <eric@anholt.net>

Based on the following commit. But for mispans.c I think the first
contained fix is wrong (nested loop with variable i) so I took another
approach.

  commit f02e27e4fcc34413b2051e5a01edc92172fa8612
  Author: Yaakov Selkowitz <yselkowitz@users.sourceforge.net>
  Date:   Tue Oct 16 02:16:17 2012 -0500

    mi: fix shadow warnings

    mibitblt.c: In function 'miGetImage':
    mibitblt.c:617:20: warning: declaration of 'pt' shadows a previous local
    mibitblt.c:609:17: warning: shadowed declaration is here
    mispans.c: In function 'miFillUniqueSpanGroup':
    mispans.c:456:33: warning: declaration of 'i' shadows a previous local
    mispans.c:382:9: warning: shadowed declaration is here
    mispans.c:488:17: warning: declaration of 'i' shadows a previous local
    mispans.c:382:9: warning: shadowed declaration is here
Signed-off-by: Yaakov Selkowitz <yselkowitz@users.sourceforge.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>

Fixes these warnings:

mi/mispans.c: fix shadowed vars

mispans.c: In function ‘miFillUniqueSpanGroup’:
mispans.c:465:12: warning: declaration of ‘i’ shadows a previous local [-Wshadow=compatible-local]
        int i;
            ^
mispans.c:387:21: note: shadowed declaration is here
     register int    i;
                     ^
mispans.c:497:10: warning: declaration of ‘i’ shadows a previous local [-Wshadow=compatible-local]
      int i;
          ^
mispans.c:387:21: note: shadowed declaration is here
     register int    i;
                     ^

mibitblt.c: In function ‘miGetImage’:
mibitblt.c:669:13: warning: declaration of ‘pt’ shadows a previous local [-Wshadow=compatible-local]
      xPoint pt;
             ^~
mibitblt.c:659:18: note: shadowed declaration is here
     DDXPointRec  pt = {0, 0};
                  ^~

Fix this warning:

xkbActions.c: In function ‘_XkbFilterDeviceBtn’:
xkbActions.c:1084:6: warning: declaration of ‘button’ shadows a previous local [-Wshadow=compatible-local]
  int button;
      ^~~~~~
xkbActions.c:1044:6: note: shadowed declaration is here
 int  button;
      ^~~~~~

Backport of this xorg-xserver upstream commit:

  commit 41dd7cf673e47ab74c5065b8dbf268b2e5facb64
  Author: Alan Coopersmith <alan.coopersmith@oracle.com>
  Date:   Mon Dec 12 16:49:34 2011 -0800

    _XkbFilterDeviceBtn: move variable declarations to match usage scope

    The main body of this function is an if { } else if { } pair of blocks.
    Previously there was int button at the top level scope which is used
    only in the first block, and a redeclaration of int button inside the
    second block.   Since there's no overlap in the code paths for the
    two uses of button, move the one from the outer block into the first
    block to help the programmer more quickly determine they are unrelated
    usages, and to silence the gcc warning of:

    xkbActions.c: In function '_XkbFilterDeviceBtn':
    xkbActions.c:999:6: warning: declaration of 'button' shadows a previous local
    xkbActions.c:955:6: warning: shadowed declaration is here

    For consistency, move DeviceIntPtr dev declarations as well that are
    used in the same way.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>