Ligatures should be done by the typesetting system.
Manuscripts should not bother with them.
Signed-off-by: James Cloos <cloos@jhcloos.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
This patch adds more friendly error messages for three common classes of
assertion:
- missed sequence numbers due to being griefed by another thread
- unknown requests in queue due to being griefed by another thread
- extensions dequeuing too much or too little reply data
It adds error messages offering advice (e.g. call XInitThreads() first)
on stderr, but still generates actual assertions. Hopefully this means
it's a little more Googleable and a little less frightening.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This provides a simplified version of the SetReqLen macro when using clang for
static analysis. Prior to this change, we would see many Idempotent operation
warnings inside this macro due to the common case of calling with arg2 and
arg3 being the same variable. This has no effect on code produced during
compilation, but it silences a number of false positives in static analysis.
XIPassiveGrab.c:170:5: warning: Assigned value is always the same as the existing value
SetReqLen(req, num_modifiers, num_modifiers);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from XIPassiveGrab.c:26:
.../include/X11/Xlibint.h:580:8: note: instantiated from:
n = badlen; \
^
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
XKBGeom.c:191:25: warning: Access to field 'x1' results in a dereference of a null pointer (loaded from variable 'rbounds')
_XkbCheckBounds(bounds,rbounds->x1,rbounds->y1);
^~~~~~~
Found-by: clang static analyzer
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
XKBGeom.c:118:27: warning: Assigned value is always the same as the existing value
for (key=row->keys,pos=k=0;k<row->num_keys;k++,key++) {
~~~^~~~
XKBGeom.c:115:5: warning: Value stored to 'pos' is never read
pos= 0;
^ ~
Found-by: clang static analyzer
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
XKBGeom.c:191:25: warning: Access to field 'x1' results in a dereference of a null pointer (loaded from variable 'rbounds')
_XkbCheckBounds(bounds,rbounds->x1,rbounds->y1);
^~~~~~~
Found-by: clang static analyzer
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
This will prevent a number of false positives in where clang's
static analysis reports about calls to malloc(0).
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
Was triggered by defined(__sparcv9) so only built on Solaris SPARC 64-bit.
Inconsistent with all other platforms, and a bit overcomplicated.
Should anyone need to continue using that path, simply build with
a #define POSTLOCALELIBDIR "sparcv9" to get the same result.
Fixes Solaris bug 7038737:
sparcv9 Xlib looking in wrong path for i18n loadable modules
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
While at it, remove unneeded check for NULL before Xfree.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan-de-oliveira@nokia.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
pScreenData is replaced when building per visual intensity tables. If
malloc failed the old value of pScreenData (stored also in
pScreenDefaultData) was being leaked. Also, property_return wasn't
free'd in that case.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan-de-oliveira@nokia.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Due to what looks like a copy & paste error, pScreenData->pBlueTbl would
be accessed after being free'd.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan-de-oliveira@nokia.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
name_ptr and detail_ptr weren't free'd in some cases before returning
False.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan-de-oliveira@nokia.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
If list_count is 0, dst would be allocated and leaked.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan-de-oliveira@nokia.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Bitmap file data is read looping through the lines in the input file. If
there is extra data after the bitmap, these lines will be processed and
if this data represents another bitmap it will replace the one read
before causing the memory allocated for bits to leak.
This changes the code to stop processing the file once a bitmap was
read.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan-de-oliveira@nokia.com>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Haven't restored the "specs" path in the install path, but have restored
libX11 & i18n subdirectories in the path for better logical grouping.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Gaetan Nadon <memsize@videotron.ca>
Moves HAVE_XMLTO check into docbook.am, more closely matches behaviour
from before docbook.am changes (commit e8c76407d2)
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Gaetan Nadon <memsize@videotron.ca>
When writing technical documentation, it is often necessary to cross
reference to other information. When that other information is not in the
current document, additional support is needed, namely <olink>.
A new feature with version 1.7 of xorg-sgml-doctools adds references to
other documents within or outside this package.
This patch adds technical support for this feature but does not change
the content of the documentation as seen by the end user.
Each book or article must generate a database containing the href
of sections that can be referred to from another document. This database
is installed in DATAROOTDIR/sgml/X11/dbs. There is a requirement that
the value of DATAROOTDIR for xorg-sgml-doctools and for the package
documentation is the same. This forms a virtual document tree.
This database is consulted by other documents while they are being generated
in order to fulfill the missing information for linking.
Refer to the xorg-sgml-doctools for further technical information.
Co-authored-by: Matt Dew <marcoz@osource.org>
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
Add #define XK_SINHALA so that the Sinhala keysyms can be used by
the lk xkb keymap.
Signed-off-by: Harshula Jayasuriya <harshula@gmail.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Historically, Xlib dropped the Display lock around the upcall to any
user-supplied _XErrorFunction, but somewhere along the way I quit doing
that if you built with XCB. The reasons are lost somewhere in the
pre-git history of Xlib/XCB, and I can't now see any reason to hold the
lock.
The documentation for XSetErrorHandler still applies though:
Because this condition is not assumed to be fatal, it is acceptable
for your error handler to return; the returned value is ignored.
However, the error handler should not call any functions (directly
or indirectly) on the display that will generate protocol requests
or that will look for input events.
So while you are now once again permitted to re-enter Xlib from the
error handler, you're only allowed to call non-protocol functions.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
This bug appears as a hang in applications that wait for replies from
multiple threads, where one such thread has taken a user lock using
XLockDisplay.
Prior to this fix, the code could deadlock in this way: If thread 1 goes
to sleep waiting for a reply, and then thread 2 takes a user lock and
waits for a reply, then thread 2 will wait for thread 1 to process its
reply (because responses must be processed in order), but thread 1 will
wait for thread 2 to drop its user lock.
Fixed by making thread 1 not wait for thread 2 to drop its user lock.
This makes the semantics of user locks hard to define, but they were
already hard to define. The new behavior appears to be consistent with
the way Xlib worked historically, anyway.
Fixes: http://lists.freedesktop.org/archives/xcb/2011-March/006802.html
There was a similar potential for deadlock in _XReadEvents, fixed the
same way, with the same caveats about user-lock semantics.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Cannot reach dead statement "return NULL;"
Check for the NULLness of prop->name and prop->value instead of
name and value, which was checked earlier anyway. Decided against
using strdup due to curious memory allocation functions and the
rest of the xkb not using it either.
Signed-off-by: Erkki Seppälä <erkki.seppala@vincit.fi>
Reviewed-by: Alan Coopersmith <alan.coopersmith at oracle.com>
Using uninitialized value "p->modifiers"
Small fix by using Xcalloc instead of Xmalloc
Signed-off-by: Erkki Seppälä <erkki.seppala@vincit.fi>
Reviewed-by: Alan Coopersmith <alan.coopersmith at oracle.com>
Variable "map" goes out of scope
Release modifiermap before returning. Reordered code to call
XGetModifierMapping after the first return from the function.
Signed-off-by: Erkki Seppälä <erkki.seppala@vincit.fi>
Reviewed-by: Dirk Wallenstein <halsmit@t-online.de>
Braille chords management needs key release events. We need to explicitly
request then, else GTK would not pass them throught XFilterEvent and braille
wouldn't work.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Braille patterns should also be usable in Compose. This combines the
implementation of braille chords and compose tree: only emit the braille
pattern if it can not be found in the compose tree, if any.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
_XimLocalMbLookupString can return a braille keysym even if _Xlcwctomb can't
convert to the current MB charset.
_XimLocalUtf8LookupString needs to set the braille keysym and status too.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Error: Memory leak (CWE 401)
Memory leak of pointer 's' allocated with XCreateRegion()
at line 387 of /export/alanc/X.Org/sx86-gcc/lib/libX11/src/Region.c in function 'XShrinkRegion'.
's' allocated at line 387 with XCreateRegion().
s leaks when s != 0 at line 387.
Error: Memory leak (CWE 401)
Memory leak of pointer 'tra' allocated with XCreateRegion()
at line 1452 of /export/alanc/X.Org/sx86-gcc/lib/libX11/src/Region.c in function 'XXorRegion'.
'tra' allocated at line 1451 with XCreateRegion().
tra leaks when tra != 0 at line 1451.
[ This bug was found by the Parfait 0.3.6 bug checking tool.
For more information see http://labs.oracle.com/projects/parfait/ ]
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
