[alsa-devel] Alsa-lib strings?
Hi,
I'm making some rust bindings for alsa-lib [1] and Rust is quite picky about strings; i e, requires them to be UTF-8.
1a) can I count on alsa-lib's strings (everything from card name and mixer identifiers to various descriptions) to be UTF-8 or perhaps even 7-bit? If not, what encoding is to be expected?
1b) In what way can buggy drivers violate the answers to 1a?
2) Can I count on the strings to be zero terminated? E g, I looked at snd_ctl_elem_id_set_name http://www.alsa-project.org/alsa-doc/alsa-lib/group___control.html#ga813d02a44a9d01a4a2fe81eda7a8670a that sets all 44 characters without ensuring a zero at the last character, but snd_ctl_elem_id_get_name http://www.alsa-project.org/alsa-doc/alsa-lib/group___control.html#gaa6cfea3ac963bfdaeb8189e03e927a76 does not say anything about a max length, it just gives out a *const char. The question applies to all other strings as well.
// David
David Henningsson wrote:
1a) can I count on alsa-lib's strings (everything from card name and mixer identifiers to various descriptions) to be UTF-8 or perhaps even 7-bit?
Alsa-lib itself does not care about the encoding.
The strings are whatever the kernel uses. In practice, this almost always means ASCII, but kernel policy is UTF-8. (At the moment, the only way I know of to get a non-ASCII string is from a USB device.)
Alsa-lib can also return strings from configuration files. These are encoded in whatever the editor happens to use, i.e., in practice, UTF-8.
1b) In what way can buggy drivers violate the answers to 1a?
The USB driver is not buggy. :) But in theory, you could get any random crap.
For testing, you can change a card's "id" attribute in sysfs.
- Can I count on the strings to be zero terminated?
In theory, yes.
snd_ctl_elem_id_set_name
Oops! Using strncpy() here is wrong.
Regards, Clemens
On Fri, 30 Sep 2016 09:50:57 +0200, Clemens Ladisch wrote:
David Henningsson wrote:
1a) can I count on alsa-lib's strings (everything from card name and mixer identifiers to various descriptions) to be UTF-8 or perhaps even 7-bit?
Alsa-lib itself does not care about the encoding.
The strings are whatever the kernel uses. In practice, this almost always means ASCII, but kernel policy is UTF-8. (At the moment, the only way I know of to get a non-ASCII string is from a USB device.)
Alsa-lib can also return strings from configuration files. These are encoded in whatever the editor happens to use, i.e., in practice, UTF-8.
1b) In what way can buggy drivers violate the answers to 1a?
The USB driver is not buggy. :) But in theory, you could get any random crap.
For testing, you can change a card's "id" attribute in sysfs.
The ID string should be OK, as it's filtered in copy_valid_id_string(). But the other name strings have no checks, thus may have non-ASCII letters (in theory).
Takashi
participants (3)
-
Clemens Ladisch -
David Henningsson -
Takashi Iwai