On Tue, Dec 26, 2017 at 01:28:34PM +0100, Kernc wrote:
> Hi,
>
> dwm 6.1-3 on ArchLinux sets WM_NAME hint on one of its windows to:
>
> "dwm\0"
>
> (with \0 being a null byte). Not certain of this, but it's what xwininfo
> reports:
>
> $ xwininfo -root -all
> Root window id: 0x126 (the root window) " X 62% | us | 59°C |
> 0.31 | 3725MB | ac 100% | Dec 26 12:42 "
> Parent window id: 0x0 (none)
> 42 children:
> ...
> 0xa0001e "dwm^_AT_": () 1x1+0+0 +0+0
> 0xa0000d (has no name): ("dwm" "dwm") 2560x19+0+0 +0+0
> ...
>
> (^_AT_ is null character in caret notation.)
>
> This makes a particular program that uses libwnck [1] fail after:
>
> Wnck-WARNING **: Property _NET_WM_NAME contained invalid UTF-8
>
> in this code [2] because the returned string contains a '\0' and the
> documentation for g_utf8_validate() [3] explicitly states that when
> string length is provided, no nul bytes are allowed.
>
> Maybe libwnck's atom string handling should be more robust, but
> since no other window ever seems to do this, I dare ask:
>
> *Why* does dwm set the title on one of its windows to "dwm\0" ?
>
>
> [1]: https://developer.gnome.org/libwnck/3.24/
> [2]: https://github.com/GNOME/libwnck/blob/4626e0290a918900da9e29b730c672950daa52db/libwnck/xutils.c#L383-L416
> [3]: https://developer.gnome.org/glib/stable/glib-Unicode-Manipulation.html#g-utf8-validate
>
Can you explain why the current behaviour is wrong? Please point to the proper X11 documentation.
The current behaviour (NUL termination) seems fine to me.
--
Kind regards,
Hiltjo
Received on Tue Dec 26 2017 - 22:09:29 CET