And instead of initializing to NULL, then resetting to LOCKDIR almost
immediately (before ever using the NULL value), skip directly to setting
it to LOCKDIR.
tmppath variable is only used as input for generating the path name
via calls to strlen, sprintf, etc.
Fixes gcc warning of:
utils.c: In function 'LockServer':
utils.c:259:11: warning: assignment discards qualifiers from pointer target type
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>
Fixes gcc warning:
io.c: In function 'WriteToClient':
io.c:826:6: warning: cast discards qualifiers from pointer target type
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>
It's only passed as the input side of a strcpy and as the filename to
fopen, so doesn't need to be non-const. Fixes gcc warning:
osinit.c: In function 'OsInit':
osinit.c:154:28: warning: initialization discards qualifiers from pointer target type
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>
Almost all of the places the string is assigned point to a literal
string constant, so use const char * for those, and const char **
for function calls that return it via an argument. Fortunately
the top level function, ClientAuthorized, which returns the string
as its return value is called from only one place, ProcEstablishConnection.
ProcEstablishConnection stores either that return value or a string literal
in char *reason. It only uses reason as an argument to SendConnSetup.
SendConnSetup passes the reason argument to strlen & WriteToClient,
both of which already have const qualifiers on their args.
Thus added const to the reason variable in ProcEstablishConnection
and the reason argument to SendConnSetup.
Fixes gcc warnings:
dispatch.c: In function 'ProcEstablishConnection':
dispatch.c:3711:9: warning: assignment discards qualifiers from pointer target type
auth.c: In function 'CheckAuthorization':
auth.c:218:14: warning: assignment discards qualifiers from pointer target type
auth.c:220:20: warning: assignment discards qualifiers from pointer target type
connection.c: In function 'ClientAuthorized':
connection.c:683:3: warning: return discards qualifiers from pointer target type
mitauth.c: In function 'MitCheckCookie':
mitauth.c:88:13: warning: assignment discards qualifiers from pointer target type
xdmauth.c:259:14: warning: assignment discards qualifiers from pointer target type
xdmauth.c:270:14: warning: assignment discards qualifiers from pointer target type
xdmauth.c:277:11: warning: assignment discards qualifiers from pointer target type
xdmauth.c:293:15: warning: assignment discards qualifiers from pointer target type
xdmauth.c:313:14: warning: assignment discards qualifiers from pointer target type
xdmauth.c:322:11: warning: assignment discards qualifiers from pointer target type
rpcauth.c: In function 'SecureRPCCheck':
rpcauth.c:136:10: warning: assignment discards qualifiers from pointer target type
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>
gcc was warning from storing string constants in a char *name field:
auth.c:64:1: warning: initialization discards qualifiers from pointer target type
auth.c:72:1: warning: initialization discards qualifiers from pointer target type
auth.c:81:1: warning: initialization discards qualifiers from pointer target type
Making the field const requires changing AuthorizationFromID to take
a const char ** pointer for the name argument which it sets to point
to the matching name entry.
Changing that argument requires changing its sole caller in the security
extension to pass the address of a const char * variable to it, which it
can do, since the only thing it does with the returned name is to pass
it back to the RemoveAuthorization function that already expects a const
char *name.
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>
No need to cast to char * now that all supported platforms use C89-standard
void * argument types, so just drop the casts from acmp & acopy macros,
which clears the gcc warnings for places const pointers were cast non-const:
access.c: In function 'DefineSelf':
access.c:786:3: warning: cast discards qualifiers from pointer target type
access.c:795:6: warning: cast discards qualifiers from pointer target type
access.c: In function 'NewHost':
access.c:1293:9: warning: cast discards qualifiers from pointer target type
access.c:1298:6: warning: cast discards qualifiers from pointer target type
access.c:1309:5: warning: cast discards qualifiers from pointer target type
Without the casts, acmp & acopy are just a funny way to write memcmp
& memmove, so drop the macros and inline the calls, taking care to
swap the first two arguments to memmove since it had swapped them.
Since all the calls to memmove end up being to non-overlapping memory
(mostly copying from an existing pointer to a newly allocated one),
replace those with memcpy.
And finally, don't actually call memcpy to copy 0 bytes from one place
to another, since that's just a waste of a perfectly good function call.
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>
MakeAtom now accepts a const char * so we don't need to cast down to
char * anymore. Fixes gcc warning of:
xres.c: In function 'ProcXResQueryClientResources':
xres.c:155:6: warning: cast discards qualifiers from pointer target type
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>
LookupResourceName already returned a const char *, so just needed
to change the variable we're storing the list in to be a const char **
and then add const to the name argument to RegisterResourceName
(which just stores name in the array) and CreateNewResourceType
(which just passes name to RegisterResourceName).
Clears a bunch of gcc warnings of the form:
registry.c:319:5: warning: passing argument 2 of 'RegisterResourceName' discards qualifiers from pointer target type
registry.c:200:1: note: expected 'char *' but argument is of type 'const char *'
and from all the extensions:
damageext.c: In function 'DamageExtensionInit':
damageext.c:490:5: warning: passing argument 2 of 'CreateNewResourceType' discards qualifiers from pointer target type
../include/resource.h:159:26: note: expected 'char *' but argument is of type 'const char *'
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>
Just use the existing n variable again in the ARGB_CURSOR loop
instead of creating another one.
Fixes gcc -Wshadow warning:
cursor.c: In function 'CheckForEmptyMask':
cursor.c:155:6: warning: declaration of 'n' shadows a previous local
cursor.c:146:9: warning: shadowed declaration is here
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>
If we didn't go into the if (!autoconfig) { } block, the filename,
dirname, and sysdirname pointers were never initialized, but we
freed them outside the block, leading to potential memory corruption.
Move the frees inside the block where they're initialized to avoid this.
To avoid similar problems, move the declarations of the variables that
are only used in this block inside the block.
Regression introduced by commit 3d635fe84d
Found by gcc warning:
xf86Config.c: In function 'xf86HandleConfigFile':
xf86Config.c:2303:11: warning: 'filename' may be used uninitialized in this function
xf86Config.c:2303:22: warning: 'dirname' may be used uninitialized in this function
xf86Config.c:2303:32: warning: 'sysdirname' may be used uninitialized in this function
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
It will never return NULL, so don't try to handle a NULL condition,
since that just confuses programmers and static analyzers.
It uses calloc, so all the allocated memory is cleared, so there's
no point looping over the memory to manually initialize it NULL.
And just because it's annoying, it doesn't need to be the only
place in this file to do if (NULL==...) instead of if (... == NULL).
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Avoids the dummy-event dance if we have an event type and need to get the
matching XI2 type.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
This is needed for touch event processing.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
It doesn't return anything, nor does it's caller expect it to.
Fixes Solaris Studio compiler error:
"xichangehierarchy.c", line 214: Function has no return statement : disable_clientpointer
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
__BUG_WARN_MSG is a simple helper to enable call with and without varargs. I
couldn't find a way to otherwise do this without getting gcc warnings.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
'state' is shadowed by the XKB 'state' as well (which feeds into the event
too), so rename this one to clarify that this is the core event state only.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
If the new cursor is the NULL cursor, don't dereference it and use zeros
instead.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
if a client had the to-be-removed device as ClientPointer, reset to NULL.
Fixes#43165
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Yes, we're likely corrupting memory here but really this is unlikely to be
triggered other than a real bug in the server. In which case a stacktrace is
going to be more useful than any silent error handling.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
The current XI2 mask handling is handy for copying (fixed size arrays) but a
pain to deal with otherwise. Add a struct for XI2 masks and the required
accessors.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Once grabs start having nested memory locations, we can't just use the
GrabRec on the stack anymore, we need to alloc/copy/free the grabs.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Not really needed at this point, but will be once touch support is added.
Since grabs are now expected to be allocated/freed with AllocGrab and
FreeGrab, CopyGrab must increase the refcount and duplicate the modifier
masks. Until the callers are switched to use FreeGrab, this introduces
memleaks.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Not needed since the GrabRec is a self-contained struct but will be needed
for the xi2 input mask rework.
FreeGrab already exists, make it available to other callers.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
No effective functionality change, just cleanup to make this code slightly
more sane.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Treat a scandir error from a missing (or unusable) directory return as
if it simply returned no files at all, which is what we want.
cc: Paulo Zanoni <przanoni@gmail.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The only kdrive server we probably care about anymore is Xephyr,
and this screen enable/disable code totally breaks it in multi-screen mode.
When you are in one screen the other stops updating.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=757457
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Pointed out by coverity.
v2: fix swapped as well, as pointed out by Alan
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
If the pGCPriv->flags == 2, then we try to assign the freed pGCPriv->XAAOps
avoid this by clearing the flags in to be destroyed pGCPriv.
Reported by coverity.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
This code had an off-by-one and would allow writing one past the end of
the callbacks array.
Pointed out by coverity.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Initialise the pAttr->values to values so if the values allocation
fails it just ends up as free(NULL).
Pointed out by coverity.
v2: use Alan's suggestion.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
So on RHEL5 anaconda sets an xorg.conf with a fixed 800x600 mode in it,
we run radeonfb and fbdev since ati won't work in userspace due to domain
issues in the older codebase.
On certain pseries blades the built-in KVM can't accept an 800x600-43 mode,
it requires the 800x600-60 mode, so we have to have the kernel radeonfb
driver reject the 800x600-43 mode when it sees it. However then fbdev
doesn't try any of the other 800x600 modes in the modelist, and we end up
getting a default 640x480 mode we don't want.
This patch changes the mode validation loop to continue on with the other modes
that match to find one that works.
v2: move code around to avoid extra loop, after comment from Jamey.
v3: move loop setup back into loop as per Jeremy's review.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
Makes things a little easier to read.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
The example at the top of the file used a struct bar and a list of struct
foos. Use those two throughout instead of a different struct foo for the
examples and for the API documentation.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Even with the documentation, the list.c tests are the best examples.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
The existing list_add() prepends to the list, but in some cases we need the
list ordered in the way we append the elements.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
The toolchain requirements are documented here:
http://www.x.org/wiki/ModularDevelopersGuide#Required_Tools
Note that autoconf features only found in versions later
than 2.60 must not be used.
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Already included during Automake initialization.
After the patch, no change:
configure:3893: checking whether make sets $(MAKE)
configure:3915: result: yes
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
