On 05/30/2013 10:26 AM, Tanu Kaskinen wrote:
On Thu, 2013-05-30 at 01:45 +0200, David Henningsson wrote:
On 05/29/2013 04:57 PM, Tanu Kaskinen wrote:
On Wed, 2013-05-22 at 14:45 +0300, Tanu Kaskinen wrote:
On Wed, 2013-05-22 at 13:33 +0200, David Henningsson wrote:
e->description is a pointer, not a fixed char array. Hence it
makes no sense to use strncmp.
This fixes a compiler warning when compiling under Ubuntu.
Signed-off-by: David Henningsson <[email protected]>
---
src/modules/module-device-manager.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/modules/module-device-manager.c
b/src/modules/module-device-manager.c
index 207870d..390046f 100644
--- a/src/modules/module-device-manager.c
+++ b/src/modules/module-device-manager.c
@@ -889,7 +889,7 @@ static pa_hook_result_t sink_new_hook_callback(pa_core *c,
pa_sink_new_data *new
name = pa_sprintf_malloc("sink:%s", new_data->name);
if ((e = entry_read(u, name))) {
- if (e->user_set_description && strncmp(e->description,
pa_proplist_gets(new_data->proplist, PA_PROP_DEVICE_DESCRIPTION), sizeof(e->description)) !=
0) {
+ if (e->user_set_description && strcmp(e->description,
pa_proplist_gets(new_data->proplist, PA_PROP_DEVICE_DESCRIPTION)) != 0) {
pa_proplist_gets() can return NULL, and if it does that, strcmp() will
crash.
Actually, I think we should make sure that all sink implementations set
PA_PROP_DEVICE_DESCRIPTION in new_data->proplist. Or even better, we
could have a separate description field in the new_data struct. I'm
dealing with sink descriptions myself currently, and I find it annoying
having to access them through proplists, and if I can't assume that the
property has been set, it's even more annoying.
Hmm, can you explain why
1) You need a PA_PROP_DEVICE_DESCRIPTION for sinks (and sources, I
assume) in the first place?
I intend to use the sink/source description as the node description too
(for nodes that are backed by a sink or source, that is - if ports
exist, they are used as the node backend instead, but not all sinks and
sources are associated with a port).
2) Why you need it so much that we should artificially create one in
all sink implementations even if there is no relevant information to add?
How could there possibly be no relevant information to add? Surely every
sink can have a sane human-readable description?
pavucontrol needs a description anyway, because it uses sinks and
sources as UI elements. For this reason I wouldn't be surprised if the
situation already was such that every sink and source sets
PA_PROP_DEVICE_DESCRIPTION.
3) Why you can't write a helper function/macro if you find it annoying
to access the proplist in several places?
My biggest worry is 2) here - we shouldn't create more information just
for the sake of it. I don't know what you want it for, but maybe a fall
back would be better - e g, using the sink description if there is no
device description property. This would be handled by the helper
function suggested in 3).
Uh, it seems that you think that sinks have a separate description in
addition to PA_PROP_DEVICE_DESCRIPTION. If they did, I'd have no
problem.
Ah, it seems you are right. The PA_PROP_DEVICE_DESCRIPTION is being used
as a de-facto description of the sink (look e g in protocol-native where
a sink description is filled in).
It's probably too risky w r t existing clients to remove it from the
proplist. And I don't like storing the same information twice, so would
it be okay to have a pa_sink_get_description function?
Then I don't mind making it mandatory, assuming you go through all
existing sink/source implementations and verify that it is filled in
correctly.
--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
