On 2012.08.27 09:03, Ludovic Rousseau wrote: >> How do you propose we address this in libusbx? > > Don't change anything in libusbx.
Well, I think at least a doc change is in order, to let daemon writers know that they may have to contend with output from libusbx to descriptor #2, even after they close stderr. While I don't think libusbx should to go as far as disabling stderr output by default, and enable it only on request, that doesn't mean we should keep something that may go contrary to expectations of daemon writers under wraps. Otherwise, the other solution I see would be for us to use a global libusbx_stderr descriptor in lieu of stderr, that defaults to stderr, and add a new API call that allows developers to set that descriptor to whatever they like, or close it, *before* libusbx init is called. This way, provided we don't screw up by introducing naked stderr output down the line, daemon writers could have an option not to have anything issued to stderr, regardless of whether LIBUSB_DEBUG is defined when the daemon is launched or whether someone replaced the shared library with a version that has forced debug logging on for instance. I'm not currently seeing such a change as being worth it, but if anyone feels strongly about that and wants to propose a patch, as long as the current default are preserved, I don't see a problem. Else, I guess it's gonna be doc update and move on. Regards, /Pete ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
