On 2012.08.24 10:10, Ludovic Rousseau wrote: > I already reported the issue in 2008 in "A library shall not write to > stderr or stdout without explicit request" [1].
"So unless explicitly requested the library shall not send anything to stdout or stderr." How do you propose we address this in libusbx? If it's start with all output off and wait for users to say they want some, that's NO_GO for me, because we want error messages to be output by default, as it's probably a fair bet to say that more than 95% usage of the library will be with users who have stderr available and want that behaviour. Thus, unless there is a safe way to detect whether stderr and stdout have been closed (but is there when we're in a library and the file no might have been reallocated long before we get to init?), I'd propose a doc change to indicate that libusbx should not close stderr, and that if libusbx users want to suppress stderr output, they should either try to adjust the log level or direct stderr to their platform's null device. IMO, trying to keep daemon writers happy will create more problems than it'll solve for the majority of libusbx users. Also, if I was linking into software I didn't write, I'd be weary to expect it never to use stderr ever, even if there was a means to ask it to. There's always the odd non-toggleable debug statement, that was introduced by the developers between releases and has been overlooked, and I'd rather assume that stderr can and will be used, and take measures around it, than have to figure out that the reason I'm seeing a weird and super rare issue is because one of my application files was reassigned fd #2. It's just not worth it IMO. 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
