`client_msg` valgrind warning: `Syscall param writev(vector[0]) points to uninitialised byte(s)`

[tuurep]

The client_msg function is used only by click-actions raise and close.

Running with valgrind gives warnings such as:

$ valgrind --leak-check=full --track-origins=yes ./raise 0x0140003d

...
==3093==
==3093== Syscall param writev(vector[0]) points to uninitialised byte(s)
==3093==    at 0x4ACA6C4: writev (writev.c:26)
==3093==    by 0x4BB13DD: UnknownInlinedFun (xcb_conn.c:296)
==3093==    by 0x4BB13DD: _xcb_conn_wait.part.0 (xcb_conn.c:553)
==3093==    by 0x4BB155F: UnknownInlinedFun (xcb_out.c:469)
==3093==    by 0x4BB155F: _xcb_out_send (xcb_out.c:470)
==3093==    by 0x4BB2A68: UnknownInlinedFun (xcb_out.c:416)
==3093==    by 0x4BB2A68: xcb_writev (xcb_out.c:409)
==3093==    by 0x48C1105: _XSend (xcb_io.c:587)
==3093==    by 0x48C5189: _XReply (xcb_io.c:679)
==3093==    by 0x48C5690: XSync (Sync.c:44)
==3093==    by 0x48A2E10: XCloseDisplay (ClDisplay.c:61)
==3093==    by 0x109100: main (raise.c:41)
==3093==  Address 0x4bea4e8 is 24 bytes inside a block of size 16,384 alloc'd
==3093==    at 0x484ABF3: calloc (vg_replace_malloc.c:1675)
==3093==    by 0x48B0BDE: XOpenDisplay (OpenDis.c:241)
==3093==    by 0x1090D8: main (raise.c:38)
==3093==  Uninitialised value was created by a stack allocation
==3093==    at 0x109222: client_msg (raise.c:6)
==3093==
...

Googling around I find something like this:

This is not necessarily a problem, other than a small security issue: The previous contents of memory, which may hold sensitive information, will get written to the file.

https://stackoverflow.com/a/5844281

Will fix, if I can figure out how.

[tuurep]

In the wmctrl code the client_msg was always given five 0s as parameters, which I just removed back then.

Initializing all five cells as 0 again gets rid of the valgrind warning.

It's cryptic to me what the purpose of data.l actually is:

https://tronche.com/gui/x/xlib/events/client-communication/client-message.html

the [...] l members represent data of [...] 5 32-bit values.

Very well then?

[tuurep]

Ah, this explains more:

https://www.x.org/releases/X11R7.5/doc/man/man3/XClientMessageEvent.3.html

The message_type member is set to an atom that indicates how the data should be interpreted by the receiving client. The format member is set to 8, 16, or 32 and specifies whether the data should be viewed as a list of bytes, shorts, or longs. The data member is a union that contains the members b, s, and l. The b, s, and l members represent data of twenty 8-bit values, ten 16-bit values, and five 32-bit values. Particular message types might not make use of all these values. The X server places no interpretation on the values in the window, message_type, or data members.

So because we set event.xclient.format = 32, we have to set the l array respectively.

But it doesn't seem hugely useful for us.