summaryrefslogtreecommitdiff
path: root/src
AgeCommit message (Collapse)AuthorFilesLines
2022-10-16Fix handling of documented enum parametersDemi Marie Obenour1-4/+5
Previously this would crash the code generator. Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
2022-10-16Fix a compiler warningDemi Marie Obenour1-2/+2
The warning is harmless but annoying. Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
2022-06-02Build DOUBLE-BUFFER extension.Mike Sharov2-0/+9
Signed-off-by: Mike Sharov <msharov@users.sourceforge.net>
2022-01-15Fix a memory leakHodong1-1/+2
Signed-off-by: Hodong <hodong@yozmos.com>
2021-11-17Fix integer overflows in xcb_in.cDemi Marie Obenour1-3/+9
This fixes an integer overflow security vulnerability in xcb_in.c, which may allow for memory corruption.
2021-09-30Fix hang in xcb_request_check()Thomas Anderson3-4/+12
This fixes https://gitlab.freedesktop.org/xorg/lib/libxcb/-/issues/53 The issue was that libxcb expected to get a reply based on the request_expected variable, but a reply would never arrive because the request was never actually written. To resolve this, a separate request_expected_written variable is added.
2021-09-30Avoid request counter truncation in replies map after 2**32 requestsRan Benita2-5/+5
The c->in request counters are uint64_t, and can realistically go over 2**32 over a lifetime of a client. The c->in->replies map however uses unsigned int keys and the passed request numbers are silently truncated. I haven't analyzed in depth what happens what it wraps around but it's probably nothing good. The only user of the xcb_list.c map code is c->in->replies, so just change it to use uint64_t keys. Reviewed-by: Uli Schlachter <psychon@znc.in> Signed-off-by: Ran Benita <ran@unusedvar.com>
2021-09-30Add newline when printing auth/connection failure string to stderrJulien Cristau1-0/+4
The reason strings returned by the server don't all include a newline, so make sure we add one to avoid confusing clients. Xlib used to do this before it delegated that work to libxcb. Fixes #34 Signed-off-by: Julien Cristau <jcristau@debian.org>
2021-09-20Improve/fix docs for reply fds functionsUli Schlachter1-2/+3
Fixes: https://gitlab.freedesktop.org/xorg/lib/libxcb/-/issues/56 Signed-off-by: Uli Schlachter <psychon@znc.in>
2021-07-30c_client.py: Implement handling of <length> elementPovilas Kanapickas1-0/+10
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
2021-07-30c_client: Extract _c_get_field_mapping_for_expr()Povilas Kanapickas1-7/+19
2021-07-30c_client.py: Use get_expr_field_names directly to resolve list fieldsPovilas Kanapickas1-1/+1
Using get_expr_fields() is only needed in case we are doing things that can span multiple types easily, e.g. when deciding what data to pass via function parameters and so on. In _c_serialize_helper_list_field() we are building function body, so acquiring field names via get_expr_field_names() is enough. Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
2021-07-30c_client.py: Extract get_expr_field_names()Povilas Kanapickas1-29/+32
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
2021-06-04Fix writev emulation on WindowsPeter Harris1-21/+36
There are at least two bugs in the previous implementation: - If an early iovec is partially written, there can be a gap of missing data (as a later iovec will be started before the early iovec is completed). - If a late iovec returns WSAEWOULDBLOCK, *vector and *count are not updated, leading to a re-send of the entire request. Move the *vector update into the send() loop to update piecemeal as individual iovecs are sent. Example program that demonstrates the issue (this program should run forever after these bugs have been fixed): #include <stdio.h> #include <stdlib.h> #include "xcb.h" // Non-cryptographic random number generator from http://burtleburtle.net/bob/rand/smallprng.html // because Microsoft's random number generators either have a too small RAND_MAX or are too slow typedef struct ranctx { uint32_t a; uint32_t b; uint32_t c; uint32_t d; } ranctx; static uint32_t ranval(ranctx *x); static void raninit(ranctx *x, uint32_t seed); #define MAX_PROP_LEN (128 * 1024) int main(int argc, char *argv[]) { uint32_t seed = 0x12345678; if (argc > 1) { seed = strtoul(argv[1], NULL, 0); } ranctx ran; raninit(&ran, seed); xcb_connection_t *c = xcb_connect(NULL, NULL); if (!c || xcb_connection_has_error(c)) { printf("Cannot connect to $DISPLAY\n"); return 1; } const xcb_setup_t *setup = xcb_get_setup(c); char *buf = malloc(MAX_PROP_LEN + 8); // plus a bit of slack so we can run random values off the end if (!buf) { printf("oom\n"); return 1; } for (uint32_t i=0; i < (MAX_PROP_LEN + 3) / 4; i++) { ((uint32_t *)buf)[i] = ranval(&ran); } xcb_window_t win = xcb_generate_id(c); xcb_create_window(c, 0, win, xcb_setup_roots_iterator(setup).data[0].root, 0, 0, 1, 1, 0, XCB_WINDOW_CLASS_INPUT_ONLY, 0, 0, NULL); printf("Created window 0x%X\n", win); for (;;) { xcb_flush(c); xcb_generic_event_t *ev = xcb_poll_for_event(c); if (ev) { if (ev->response_type == 0) { xcb_generic_error_t *err = (xcb_generic_error_t *)ev; printf("Unexpected X Error %d\n", err->error_code); printf(" Sequence %d\n", err->sequence); printf(" Resource ID 0x%X\n", err->resource_id); printf(" Opcode: %d.%d\n", err->major_code, err->minor_code); return 1; } printf("Unexpected X Event %d\n", ev->response_type); return 1; } uint32_t siz = ranval(&ran) % MAX_PROP_LEN + 1; xcb_change_property(c, XCB_PROP_MODE_REPLACE, win, XCB_ATOM_STRING, XCB_ATOM_STRING, 8, siz, buf); } return 0; } #define rot(x,k) (((x)<<(k))|((x)>>(32-(k)))) static uint32_t ranval(ranctx *x) { uint32_t e = x->a - rot(x->b, 27); x->a = x->b ^ rot(x->c, 17); x->b = x->c + x->d; x->c = x->d + e; x->d = e + x->a; return x->d; } static void raninit(ranctx *x, uint32_t seed) { uint32_t i; x->a = 0xf1ea5eed, x->b = x->c = x->d = seed; for (i = 0; i<20; ++i) { (void)ranval(x); } } Signed-off-by: Peter Harris <pharris@opentext.com>
2021-06-04Fix build on WindowsPeter Harris6-6/+34
Notable changes: Protect include of unistd.h (and other POSIX headers). Use SOCKET (which is larger than int) and closesocket (because close is not compatible) for sockets. Use <stdint.h>'s intptr_t instead of the non-portable ssize_t. Signed-off-by: Peter Harris <pharris@opentext.com>
2021-06-01xcb_auth: Quiet -Wimplicit-fallthrough warning in get_authptr()Alan Coopersmith2-0/+11
xcb_auth.c:135:14: warning: this statement may fall through [-Wimplicit-fallthrough=] addr += 12; ~~~~~^~~~~ xcb_auth.c:138:5: note: here case AF_INET: ^~~~ Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
2021-02-02Increment libtool version info for libxcb-dri3Julien Cristau1-1/+1
Somewhat belatedly given the last update was in xcb-proto 1.13 in 2017... Quoting @smcv from https://bugs.debian.org/921069: >>> libxcb-dri3 version 1.13 appears to have added new symbols without increasing the minor ABI version in its -version-info. This will break anything that compares libraries by their version info to decide which one is newer. The Steam Runtime uses libraries' major/minor/micro ABI version info (in this case 0.0.0) to decide whether to use the system copy of a library or the copy in the Steam Runtime, depending on which one is newer (#921026). We can work around this by adding a versioned dependency on libxcb-dri3-0 and deleting the copy from the Steam Runtime, but this isn't a particularly scalable solution. >>>
2020-03-02Use the 'present' field to properly check that the XC-MISCEduardo Sánchez Muñoz2-2/+2
extension is available in xcb_generate_id. Also document the returned value when xcb_generate_id fails.
2020-02-22Implement xcb_total_read() and xcb_total_written().Sam Varshavchik4-0/+60
Returns raw byte counts that have been read or written to the xcb_connection_t. I found it very useful when developing a high level widget toolkit, to track down inefficient/sub-optimum code that generates a lot of X protocol traffic. Signed-off-by: Sam Varshavchik <mrsam@courier-mta.com>
2019-05-19Handle EINTR from recvmsg in _xcb_in_readMartin Dørum1-1/+1
I have a GTK application which occasionally crashes with an "interrupted system call" g_message from gdk. After a lot of debugging, I've found that the call to recvmsg in _xcb_in_read occasionally fails with EINTR, and instead of retrying the system call, xcb would just shut down the connection. This change makes _xcb_in_read treat EINTR the same as it would treat EAGAIN; it returns 1 and libX11 ends up calling xcb_poll_for_event again (from what I have understood). I have spoken with a few people who think recvmsg failing with EINTR in this case shouldn't ever happen, and I don't know enough to agree or disagree with that. In case anyone wants to dig further and try to figure out why the recvmsg call sometimes fails with EINTR, here's the backtrace from inside of _xcb_in_read where that happened: Thread 1 "beanbar" hit Breakpoint 1, _xcb_in_read (c=c@entry=0x55ecbe4aba80) at xcb_in.c:1059 1059 fprintf(stderr, "Hello World am %s:%i, errno is %s\n", __FILE__, __LINE__, strerror(errno)); (gdb) bt 0 0x00007fa48fa48639 in _xcb_in_read (c=c@entry=0x55ecbe4aba80) at xcb_in.c:1059 1 0x00007fa48fa489d8 in poll_for_next_event (c=0x55ecbe4aba80, queued=queued@entry=0) at xcb_in.c:352 2 0x00007fa48fa48a3d in poll_for_next_event (queued=0, c=<optimized out>) at xcb_in.c:722 3 0x00007fa48fa48a3d in xcb_poll_for_event (c=<optimized out>) at xcb_in.c:722 4 0x00007fa4908d1b7e in poll_for_event (dpy=dpy@entry=0x55ecbe4a9730, queued_only=queued_only@entry=0) at xcb_io.c:245 5 0x00007fa4908d1cf0 in poll_for_response (dpy=dpy@entry=0x55ecbe4a9730) at xcb_io.c:303 6 0x00007fa4908d1fed in _XEventsQueued (mode=2, dpy=0x55ecbe4a9730) at xcb_io.c:363 7 0x00007fa4908d1fed in _XEventsQueued (dpy=dpy@entry=0x55ecbe4a9730, mode=mode@entry=2) at xcb_io.c:344 8 0x00007fa4908c3d47 in XPending (dpy=0x55ecbe4a9730) at Pending.c:55 9 0x00007fa493cadbc7 in () at /usr/lib/libgdk-3.so.0 10 0x00007fa49234d08a in g_main_context_prepare () at /usr/lib/libglib-2.0.so.0 11 0x00007fa49234d6e6 in () at /usr/lib/libglib-2.0.so.0 12 0x00007fa49234d8ae in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0 13 0x00007fa4938b920e in g_application_run () at /usr/lib/libgio-2.0.so.0 14 0x000055ecbc820af4 in main (argc=1, argv=0x7ffd06238098) at src/main.c:190 Signed-off-by: Martin Dørum <martid0311@gmail.com>
2019-04-25Include time.h before using time()Jon Turney1-0/+1
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
2019-02-17Add "ge.*" to src/.gitignoreEduardo Sánchez Muñoz1-0/+1
2019-01-07c_client: fix "adress" typoAlan Coopersmith1-1/+1
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
2018-08-21don't flag extra reply in xcb_take_socketErik Kurzinger2-4/+22
If any flags are specified in a call to xcb_take_socket, they should only be applied to replies for requests sent after that function returns (and until the socket is re-acquired by XCB). Previously, they would also be incorrectly applied to the reply for the last request sent before the socket was taken. For instance, in this example program the reply for the GetInputFocus request gets discarded, even though it was sent before the socket was taken. This results in the call to retrieve the reply hanging indefinitely. static void return_socket(void *closure) {} int main(void) { Display *dpy = XOpenDisplay(NULL); xcb_connection_t *c = XGetXCBConnection(dpy); xcb_get_input_focus_cookie_t cookie = xcb_get_input_focus_unchecked(c); xcb_flush(c); uint64_t seq; xcb_take_socket(c, return_socket, dpy, XCB_REQUEST_DISCARD_REPLY, &seq); xcb_generic_error_t *err; xcb_get_input_focus_reply(c, cookie, &err); } In practice, this has been causing intermittent KWin crashes when used in combination with the proprietary NVIDIA driver such as https://bugs.kde.org/show_bug.cgi?id=386370 since when Xlib fails to retrieve one of these incorrectly discarded replies it triggers an IO error. Signed-off-by: Erik Kurzinger <ekurzinger@nvidia.com> Signed-off-by: Uli Schlachter <psychon@znc.in>
2017-06-05c_client: Add support for lists of FDsDaniel Stone1-9/+29
Matching xcbgen changes, add support having a ListType which contains file descriptors. Use this to send a variable number of FDs to the server, including when the list size is not fixed. Signed-off-by: Daniel Stone <daniels@collabora.com>
2017-06-05c_client: Don't serialise non-wire fieldsDaniel Stone1-5/+9
For when we have a variable-sized field followed by a fixed field, make sure we do not serialise non-wire fields. Signed-off-by: Daniel Stone <daniels@collabora.com>
2017-05-13read from connection when polling special events and repliesDavid McFarland1-0/+6
Using the mesa vulkan driver, if you acquire an image from a swapchain using a finite timeout (x11_acquire_next_image_poll_x11), it will occasionally lock, calling xcb_poll_for_special_event in a loop until the timeout expires. Call _xcb_in_read() once from the polling functions for special events and replies, in the same way as xcb_poll_for_event. Signed-off-by: David McFarland <corngood@gmail.com> Signed-off-by: Uli Schlachter <psychon@znc.in>
2017-04-01Check strdup for NULL return value.Tobias Stoeckmann1-0/+2
_xcb_open does not check strdup's return value for NULL if launchd suport was configured. Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org> Signed-off-by: Uli Schlachter <psychon@znc.in>
2017-03-11add support for eventstructChristian Linhart2-1/+43
eventstruct allows to use events as part of requests. This is, e.g., needed by xcb_input_send_extension_event. Signed-off-by: Christian Linhart <chris@demorecorder.com>
2017-03-11optionally build the GE extensionChristian Linhart1-0/+7
xcb contains an xml-definition for the GenericEvent extension but this extension was neither generated nor built. This patch enables optional building of the GenericEvent extension with configure option --enable-ge By default, the GenericEvent extension is not built. Normally this is not needed by application programs because there is implicit support for the GE-extension for the specific events built with this extension. But it may be useful for X-protocol analyzers and stuff like that. Signed-off-by: Christian Linhart <chris@demorecorder.com>
2017-03-11move symbol lookup of sumof expr to the parserChristian Linhart1-8/+1
replace the complicated symboltable lookup for sumof expr by accessing the lenfield of the expr-object. This requires the corresponding patch for xcb/proto which sets the lenfield accordingly. This should be OK because for official releases we define that dependency in the build system. For getting versions off the HEAD of the git repo, it should be obvious that xcb/proto and xcb/libxcb have to be updated together. I have tested this patch and it generates exactly the same code as before. Tested-by: Christian Linhart <chris@demorecorder.com> Signed-off-by: Christian Linhart <chris@demorecorder.com>
2016-05-29Correct @param "e" to "error" in xcb_poll_for_reply*()Alan Coopersmith1-2/+2
Found by clang -Wdocumentation: ./xcbext.h:271:11: warning: parameter 'e' not found in the function declaration [-Wdocumentation] * @param e Location to store errors in, or NULL. Ignored for un... ^ ./xcbext.h:271:11: note: did you mean 'error'? * @param e Location to store errors in, or NULL. Ignored for un... ^ error ./xcbext.h:283:11: warning: parameter 'e' not found in the function declaration [-Wdocumentation] * @param e Location to store errors in, or NULL. Ignored for un... ^ ./xcbext.h:283:11: note: did you mean 'error'? * @param e Location to store errors in, or NULL. Ignored for un... ^ error Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Signed-off-by: Uli Schlachter <psychon@znc.in>
2016-05-29Remove : from @param names in manually written headersAlan Coopersmith2-83/+83
Makes style match the @param names in autogenerated headers and makes clang -Wdocumentation stop complaining about all of them: ./xcb.h:523:11: warning: parameter 'display:' not found in the function declaration [-Wdocumentation] * @param display: A pointer to the display number. ^~~~~~~~ ./xcb.h:523:11: note: did you mean 'display'? * @param display: A pointer to the display number. ^~~~~~~~ display Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Signed-off-by: Uli Schlachter <psychon@znc.in>
2016-05-28Fix inconsistent use of tabs vs. space.Thomas Klausner1-7/+7
Needed for at least python-3.5.x. Signed-off-by: Thomas Klausner <wiz@NetBSD.org> Signed-off-by: Uli Schlachter <psychon@znc.in>
2016-02-01Increase unix socket send buffer to at least 64KBMark Kettenis1-0/+7
Some systems (e.g. OpenBSD) have a rather small default socket send buffer size of 4KB. The result is that sending requests with a largish payload requires serveral writev(2) system calls. Make sure the socket send buffer is at least 64KB such that we're likely to succeed with a single system call for most requests. A similar change was made to the xtrans code some time ago. Signed-off-by: Mark Kettenis <kettenis@openbsd.org> Reviewed-by: Matthieu Herrb <matthieu@herrb.eu>
2016-02-01do not serialize pads by default anymoreChristian Linhart1-1/+2
Pads should not be serialized/deserialized to maintain ABI compatibility when adding explicit align pads. Therefore this pad switches off serialization of pads unless it is enforced by serialize=true in the xml-definition of that pad Signed-off-by: Christian Linhart <chris@demorecorder.com>
2016-01-06calculate lengthless listJaya Tiwari1-22/+62
Some rework done by Christian Linhart Signed-off-by: Jaya Tiwari <tiwari.jaya18@gmail.com> Signed-off-by: Christian Linhart <chris@demorecorder.com>
2016-01-06Fix handling of align-pads in end-iteratorsChristian Linhart1-2/+3
If a list is preceded by an align-pad, then accessor for the end-iterator returned a wrong value. Reason: the length of the align-iterator was added to a pointer of list-member type. Therefore, the length was multiplied by the size of the list-member type, due to C pointer arithmetic rules. This has looked like the following, e.g., in xcb_randr_get_crtc_transform_pending_params_end: i.data = ((xcb_render_fixed_t *) prev.data) + ((-prev.index) & (4 - 1)) + (R->pending_nparams); This bug was introduced with the following commit: http://cgit.freedesktop.org/xcb/libxcb/commit/?id=4033d39d4da21842bb1396a419dfc299591c3b1f The fix handles this by casting to char* before adding the align, and then casting the result to the member type. Signed-off-by: Christian Linhart <chris@demorecorder.com>
2016-01-06set the align-offset as provided by protoChristian Linhart1-8/+10
instead of using the lower bits of the pointer address. This fixes a bug reported by Peter Hutterer in off-list communication back in June 2015. This requires the alignment-checker patches in xcb/proto. Signed-off-by: Christian Linhart <chris@demorecorder.com>
2015-08-13make lists after align-pads workChristian Linhart1-4/+10
Handle align-pads when generating an end-function in the same way as handling them when generating an accessor or iterator function. Signed-off-by: Christian Linhart <chris@demorecorder.com>
2015-07-04make support for server side stuff optionalChristian Linhart2-2/+14
and make it disabled by default with an EXPERIMENTAL warning reason: this feature is unfinished and we want to have flexibility for ABI/API changes, while still being able to make a release soon Signed-off-by: Christian Linhart <chris@demorecorder.com>
2015-06-25Fix a thread hang with xcb_wait_for_special_event()Uli Schlachter2-0/+33
Consider the following: - Two threads are calling xcb_wait_for_special_event() and xcb_wait_for_reply() concurrently. - The thread doing xcb_wait_for_reply() wins the race and poll()s the socket for readability. - The other thread will be put to sleep on the special_event_cond of the special event (this is done in _xcb_conn_wait() via the argument xcb_wait_for_special_event() gives it). - The first thread gets its reply, but does not yet receive any special event. In this case, the first thread will return to its caller. On its way out, it will call _xcb_in_wake_up_next_reader(), but that function cannot wake up anything since so far it did not handle xcb_wait_for_special_event(). Thus, the first thread stays blocked on the condition variable and no thread tries to read from the socket. A test case demonstrating this problem is available at the bug report. Fix this similar to how we handle this with xcb_wait_for_reply(): The function wait_for_reply() adds an entry into a linked list of threads that wait for a reply. Via this list, _xcb_in_wake_up_next_reader() can wake up this thread so that it can call _xcb_conn_wait() again and then poll()s the socket. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84252 Signed-off-by: Uli Schlachter <psychon@znc.in> Tested-by: Michel Dänzer <michel.daenzer@amd.com>
2015-06-12Call _xcb_wake_up_next_reader from xcb_wait_for_special_eventMichel Dänzer1-0/+1
All functions calling _xcb_conn_wait() must make sure that waiting readers are woken up when we read a reply or event that they are waiting for. xcb_wait_for_special_event() did not do so. This adds the missing call to_xcb_in_wake_up_next_reader(). Fixes deadlock when waiting for a special event and concurrently processing the display connection queue in another thread. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84252 Tested-by: Thomas Daede <bztdlinux@gmail.com> Tested-by: Clément Guérin <geecko.dev@free.fr> Reviewed-by: Uli Schlachter <psychon@znc.in> Signed-off-by: Michel Dänzer <michel@daenzer.net> Signed-off-by: Uli Schlachter <psychon@znc.in>
2015-06-12send_fds(): Handle too many outstanding FDs to sendUli Schlachter1-3/+11
Before this patch, the following code caused an endless loop in send_fds(), because the queue of FDs to send was eventually full, but _xcb_out_flush_to() didn't make any progress, since there was no request to send: while (1) { xcb_send_fd(conn, dup(some_fd)); } Fix this by sending a sync when flushing didn't make any progress. That way we actually have something to send and can attach the pending FDs. Because send_fds() can now send requests, the code in xcb_send_request_with_fds64() has to be changed. It has to call send_fds() before it establishes a good sequence number for the request it wants to send. Signed-off-by: Uli Schlachter <psychon@znc.in>
2015-06-12Code generator: Use xcb_send_request_with_fds()Uli Schlachter1-2/+10
Signed-off-by: Uli Schlachter <psychon@znc.in>
2015-06-12Add xcb_send_request_with_fds() and *_with_fds64()Uli Schlachter2-9/+90
Doing xcb_send_fd(), xcb_send_request() is racy. If two threads do this at the same time, they could mix up their file descriptors. This commit makes it possibly to fix this race by providing a single function which does everything that is needed. Signed-off-by: Uli Schlachter <psychon@znc.in>
2015-06-12send_fds(): Make sure no other thread interrupts usUli Schlachter1-0/+9
Two threads trying to send fds at the same time could interfere. To guarantee a correct ordering, we have to use correct locking. The code in send_fds() missed one case: If there was another thread already writing requests, we slept on the "done with writing" condition variable (c->out.cond). This would allow other threads to re-acquire the iolock before us and could cause fds to be sent out of order. To fix this, at the beginning of send_fds() we now make sure that no other thread is already writing requests. This is what prepare_socket_request() does. Additionally, it gets the socket back in case xcb_take_socket() was called, which is a good thing, too, since fds are only sent with corresponding requests.
2015-06-12xcb_send_fd(): Always close fdsUli Schlachter1-10/+34
The API docs for xcb_send_fd() says "After this function returns, the file descriptor given is owned by xcb and will be closed eventually". Let the implementation live up to its documentation. We now also close fds if fd passing is unavailable (!HAVE_SENDMSG) and when the connection is in an error state. (This also does sneak in some preparatory functions for follow-up commits and thus does things in a more complicated way than really necessary.) Signed-off-by: Uli Schlachter <psychon@znc.in>
2015-05-30c_client.py: don't generate useless empty /** < */ commentsRan Benita1-42/+42
(This does not change doxygen's output or warnings). Signed-off-by: Ran Benita <ran234@gmail.com> Reviewed-by: Christian Linhart <chris@demorecorder.com>
2015-05-30c_client.py: use pattern matching with enumerate()Ran Benita1-4/+3
Signed-off-by: Ran Benita <ran234@gmail.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-18 18:30:54 +0000