Helper function for retrieving the owning client of a grab.
It's an actual function, so callers don't need access to internal
knowledge (definition of GrabRec, clients[] array, ...)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Hide internals (drop the need to include windowstr.h), make it typesafe
as well as the naming easier to understand.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Protect the Add() proto funcs from adding duplicate auth keys.
If adding a duplicate is attempted, the XID of the already
existing one is returned instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for loading the address into temporary variable and later doing
indirect call, since we can easily do direct call in each branch.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
XID = 0 already is used as sign for error in several places,
so let's use that here, too.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Generate the auth object XIDs inside the proto funcs and only
on success, so we don't unnecessarily allocate XIDs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to explicitly hard-code strings lengths when we can use
standard strlen(). Those code pathes are so cold that trying to
spare a few cycled for an (usually inlined) strlen() doesn't seem
to justify any extra care.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The code is easier to understand, but also more robust (eg. against struct
layout changes) if structs are initialized with explicit field names
instead of as lists.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Some callers treating XID = 0 as a sign for non-existing resource.
Practically should not happen, but nevertheless adding extra
protection, just in case.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The old PCCONS driver only seems to be used on minimal install disks and
cannot coexist with newer ones (at least that's the feedback I've gotten
from BSD community), so there's probably no practical use case for
supporting it in Xorg anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Now that the name clash on GC type between Xserver and xlib has been fixed,
there's no need to do the special renaming hack anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Both xlib as well as the Xserver use the same identifier "GC" for
different types. While on xlib it's just the numerical ID of a GC,
the xserver defines a struct for it by the same name. This is this
ugly and needs ridiculous hacks for Xserver code that needs xlib.
Easy to solve by just renaming the GC typedef to GCRec (consistent
with how we're naming other structs) and replacing GC* by GCPtr.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The function actually operates on ClientRec, so we can pass it in
directly, so it doesn't need to fetch it from clients[] array itself.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's only caller already has a pointer to client struct, so no need to
let this function look it up again in the global clients array.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to have it ripped into two pieces, just making upcoming
changes more complicated.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Align the function's parameter names with those defined in the prototype.
Especially it makes code easier to understand if the result parameter
is also named "result" here, as in the prototype.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Improve in-code docs of some request handlers, so it becomes a bit
more obvious what they're doing.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Pass each client we're considering to report through XaceHookClientAccess(),
so security extensions have a chance to filter them out.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Pass each client we're considering to report through XaceHookClientAccess(),
so security extensions have a chance to filter them out.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Pass each client we're considering to report through XaceHookClientAccess(),
so security extensions have a chance to filter them out.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Pass each client we're considering to report through XaceHookClientAccess(),
so security extensions have a chance to filter them out.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This header isn't part of SDK and no external module using those functions,
so no need to keep them exported.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This header needs to be included first, otherwise things can easily get really
messed up. The current code only works by accident, because some other header
already including it early enough - but a subtle change in include order
can easy break it.
Thus, always make sure the header is really included first.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This header needs to be included first, otherwise things can easily get really
messed up. The current code only works by accident, because some other header
already including it early enough - but a subtle change in include order
can easy break it.
Thus, always make sure the header is really included first.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This header needs to be included first, otherwise things can easily get really
messed up. The current code only works by accident, because some other header
already including it early enough - but a subtle change in include order
can easy break it.
Thus, always make sure the header is really included first.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This header needs to be included first, otherwise things can easily get really
messed up. The current code only works by accident, because some other header
already including it early enough - but a subtle change in include order
can easy break it.
Thus, always make sure the header is really included first.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Enrico Weigelt, metux IT consult