[alsa-devel] [PATCH] ALSA: Warn when control names are truncated
This is likely to confuse user interfaces since the end of the control name is interpreted (eg, "Volume", "Switch"). Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> --- sound/core/control.c | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/sound/core/control.c b/sound/core/control.c index 6d71f9a..b0bf426 100644 --- a/sound/core/control.c +++ b/sound/core/control.c @@ -225,8 +225,13 @@ struct snd_kcontrol *snd_ctl_new1(const struct snd_kcontrol_new *ncontrol, kctl.id.iface = ncontrol->iface; kctl.id.device = ncontrol->device; kctl.id.subdevice = ncontrol->subdevice; - if (ncontrol->name) + if (ncontrol->name) { strlcpy(kctl.id.name, ncontrol->name, sizeof(kctl.id.name)); + if (strcmp(ncontrol->name, kctl.id.name) != 0) + snd_printk(KERN_WARNING + "Control name '%s' truncated to '%s'\n", + ncontrol->name, kctl.id.name); + } kctl.id.index = ncontrol->index; kctl.count = ncontrol->count ? ncontrol->count : 1; access = ncontrol->access == 0 ? SNDRV_CTL_ELEM_ACCESS_READWRITE : -- 1.5.6.5
At Wed, 29 Oct 2008 14:40:30 +0000, Mark Brown wrote:
This is likely to confuse user interfaces since the end of the control name is interpreted (eg, "Volume", "Switch").
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Thanks, applied now. Takashi
--- sound/core/control.c | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/sound/core/control.c b/sound/core/control.c index 6d71f9a..b0bf426 100644 --- a/sound/core/control.c +++ b/sound/core/control.c @@ -225,8 +225,13 @@ struct snd_kcontrol *snd_ctl_new1(const struct snd_kcontrol_new *ncontrol, kctl.id.iface = ncontrol->iface; kctl.id.device = ncontrol->device; kctl.id.subdevice = ncontrol->subdevice; - if (ncontrol->name) + if (ncontrol->name) { strlcpy(kctl.id.name, ncontrol->name, sizeof(kctl.id.name)); + if (strcmp(ncontrol->name, kctl.id.name) != 0) + snd_printk(KERN_WARNING + "Control name '%s' truncated to '%s'\n", + ncontrol->name, kctl.id.name); + } kctl.id.index = ncontrol->index; kctl.count = ncontrol->count ? ncontrol->count : 1; access = ncontrol->access == 0 ? SNDRV_CTL_ELEM_ACCESS_READWRITE : -- 1.5.6.5
On Wed, 29 Oct 2008, Takashi Iwai wrote:
At Wed, 29 Oct 2008 14:40:30 +0000, Mark Brown wrote:
This is likely to confuse user interfaces since the end of the control name is interpreted (eg, "Volume", "Switch").
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Thanks, applied now.
+ if (strcmp(ncontrol->name, kctl.id.name) != 0)
Maybe better is to just use end char comparsion to save few CPU ticks: if (kctl.id.name[sizeof(kctl.id.name)-2] != '\0' && ncontrol->name[sizeof(kctl.id.name)-1] != '\0') print_warning_here; Jaroslav ----- Jaroslav Kysela <perex@perex.cz> Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
At Wed, 29 Oct 2008 15:51:40 +0100 (CET), Jaroslav Kysela wrote:
On Wed, 29 Oct 2008, Takashi Iwai wrote:
At Wed, 29 Oct 2008 14:40:30 +0000, Mark Brown wrote:
This is likely to confuse user interfaces since the end of the control name is interpreted (eg, "Volume", "Switch").
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Thanks, applied now.
+ if (strcmp(ncontrol->name, kctl.id.name) != 0)
Maybe better is to just use end char comparsion to save few CPU ticks:
if (kctl.id.name[sizeof(kctl.id.name)-2] != '\0' && ncontrol->name[sizeof(kctl.id.name)-1] != '\0')
No, this may cause segfault (and way too hacky to understand what's the purpose of the code...) Takashi
On Wed, Oct 29, 2008 at 03:51:40PM +0100, Jaroslav Kysela wrote:
Maybe better is to just use end char comparsion to save few CPU ticks:
if (kctl.id.name[sizeof(kctl.id.name)-2] != '\0' && ncontrol->name[sizeof(kctl.id.name)-1] != '\0') print_warning_here;
It will be but given that this only happens when controls are created I'd be surprised if performance were a practical issue.
On Wed, 29 Oct 2008, Takashi Iwai wrote:
At Wed, 29 Oct 2008 15:51:40 +0100 (CET), Jaroslav Kysela wrote:
On Wed, 29 Oct 2008, Takashi Iwai wrote:
At Wed, 29 Oct 2008 14:40:30 +0000, Mark Brown wrote:
This is likely to confuse user interfaces since the end of the control name is interpreted (eg, "Volume", "Switch").
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Thanks, applied now.
+ if (strcmp(ncontrol->name, kctl.id.name) != 0)
Maybe better is to just use end char comparsion to save few CPU ticks:
if (kctl.id.name[sizeof(kctl.id.name)-2] != '\0' && ncontrol->name[sizeof(kctl.id.name)-1] != '\0')
No, this may cause segfault
How? The first check in the fixed size variable initialized with zeros allocated on heap ensures that ncontrol->name string is at least sizeof(kctl.id.name) long. There is no possibility of segfault.
(and way too hacky to understand what's the purpose of the code...)
The printk explains check nicely. Jaroslav ----- Jaroslav Kysela <perex@perex.cz> Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.
At Wed, 29 Oct 2008 19:31:25 +0100 (CET), Jaroslav Kysela wrote:
On Wed, 29 Oct 2008, Takashi Iwai wrote:
At Wed, 29 Oct 2008 15:51:40 +0100 (CET), Jaroslav Kysela wrote:
On Wed, 29 Oct 2008, Takashi Iwai wrote:
At Wed, 29 Oct 2008 14:40:30 +0000, Mark Brown wrote:
This is likely to confuse user interfaces since the end of the control name is interpreted (eg, "Volume", "Switch").
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Thanks, applied now.
+ if (strcmp(ncontrol->name, kctl.id.name) != 0)
Maybe better is to just use end char comparsion to save few CPU ticks:
if (kctl.id.name[sizeof(kctl.id.name)-2] != '\0' && ncontrol->name[sizeof(kctl.id.name)-1] != '\0')
No, this may cause segfault
How? The first check in the fixed size variable initialized with zeros allocated on heap ensures that ncontrol->name string is at least sizeof(kctl.id.name) long. There is no possibility of segfault.
Hm, OK, this would work indeed surprisingly.
(and way too hacky to understand what's the purpose of the code...)
The printk explains check nicely.
Uh, no. The problem is that you'll likely need to consider what really the code does and even whether it's correct at the first glance. That's definitely bad for readability. Since the code path is absolutely no fast path and a rarely used path, there is no win at all in practice for such a nano optimization. Takashi
participants (3)
-
Jaroslav Kysela -
Mark Brown -
Takashi Iwai