| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
|
|
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
|
|
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
|
|
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
|
|
389e01fb51ba2d708015e27d8fc17c88a0e55802
Signed-off-by: Benjamin Close <Benjamin.Close@clearchain.com>
|
|
This reverts commit d192bac409fe5ef99fa9fb9b5a0d5f656f0f1412.
When transport.c is directly include (as in the case of libICE:icetrans.c:32)
Xtranssock.c must be included before Xtransutil.c in order for the socket
structures to be included. Including Xtransutil.c after Xtranssock.c requires
is_number and trans_mkdir to be defined.
This reintroduces the warning until a cleaner solution can be found
but fixes the build.
Found by: Tinderbox
Signed-off-by: Benjamin Close <Benjamin.Close@clearchain.com>
|
|
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
|
|
The #ifdef ICE_t case in Xtransutil.c depended on some #includes that
are done in files that transport.c previously included before Xtransutil.c
but are now after Xtransutil.c is included.
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
|
|
The functions are declared static in Xtransint.h but are defined
in Xtransutil.c. So when someone (xserver/os/connection.c)
incuded Xtransint.h, gcc would throw the warning.
I removed the declarations from the header and rearranged includes
in transport.c so that Xtransutil.c is included just after
Xtransint.h. This way the functions are still defined for the
files that need them (Xtranssock.c, Xtranstli.c).
Signed-off-by: Tomas Carnecky <tom@dbservice.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
|
|
Signed-off-by: Tomas Carnecky <tom@dbservice.com>
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
|
|
Compiler warnings are spread on other packages, with a
warning in the format:
/usr/include/X11/Xtrans/Xtranssock.c:548: warning: 'ciptr' may be used uninitialized in this function
so the code was slightly changed so that the compiler
would not "think" it could be used without initialization.
|
|
|
|
|
|
|
|
X.Org Bug #18748 <http://bugs.freedesktop.org/show_bug.cgi?id=18748>
|
|
|
|
|
|
|
|
This hasn't been consumed in the server or libs since 7.0.
|
|
If your OS doesn't have sysconf(3), then life is already hard for you.
|
|
|
|
skip checking xauth" for use with Apple launchd sockets.
|
|
addition code in the server isn't bulletproof yet.
|
|
|
|
|
|
|
|
|
|
Apropos of bug #15884.
|
|
Red Hat bug #445303.
|
|
|
|
|
|
|
|
|
|
|
|
Since the struct has a fixed-lenght char[] its sizeof() contains
trailing NUL octets which results in corrupt abstract sockets.
Instead, take the strlen(3) of the path, plus the single NUL octet
(which identifies the path as an abstract path rather than a file-
system path) plus the offset from the start of the struct to the
start of the char array.
This fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=15677
|
|
error condition.
|
|
Check for socklen_t definition and if found use it instead of size_t or
int for the length argument to getpeername/getsockname/etc.
<http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6688467>
|
|
If the socket isn't there, it's not gonna magically appear. Either it's
a server socket and you should have just waited for the SIGUSR1 from the
server, or it's a stale reference to an ICE socket.
However, do retry once, so fallback from abstract to filesystem namespace
works.
Originally Debian bug #385976.
|
|
GNU/kFreeBSD defines BSD44SOCKETS, but doesn't have SOCK_MAXADDRLEN.
Check for the latter directly.
|
|
|
|
Unlike normal unix sockets, the abstract namespace is not bound to the
filesystem. This has some notable advantages; /tmp need not exist, the
socket directory need not have magic permissions, etc. xtrans servers
will listen on both the normal and abstract socket endpoints; clients
will attempt to connect to the abstract socket before connecting to the
corresponding filesystem socket.
Based on a patch by Bill Crawford.
|
|
"""
It's simply obsolete, sloppy, compiler namespace pollution. The
compiler is not allowed to predefine symbols that might conflict with
ordinary identifiers. For backwards compatibility gcc currently
predefines i386 when compiling for x86 32-bit (but not 64-bit), but that
will go away. It is also not defined if you specify -ansi when invoking
the compiler, because then it is seriously standards compliant. Other
compilers shouldn't define it either. Correct code shouldn't rely on it
being defined. However __i386__ is safe and proper.
"""
|
|
|
|
|
|
|
|
* Xtranssock.c: (SocketReopen): oops fix a typo in my last commit.
|
|
* Xtranssock.c:
(SocketReopen): protect use of BSD4.4 socket with BSD44SOCKETS macro.
protect use of strlcnpy with HAVE_STRLCPY macro.
That one is defined (or not) by the xserver configure.
|
|
|
|
We don't need to warn the user about the fact that the socket
directory is not owned by root under OS X; on that platform,
it's never owned by root, as the X server runs as the normal user.
|
|
|
