07.11.2010 14:32, Max Kellermann пишет: > "a pathname in the GLib file name encoding (UTF-8 on Windows)"
Probably this is a documentation ambiguity and authors really meant "a pathname in the file name encoding" > Not a show stopper, just a problem we need to be aware of. Those > decoders which don't have I/O callbacks may not be able to play some > files. Or maybe there is a workaround for narrow characters? I think common ones like libflac, libvorbis and libmad will work. This needs some investigation what exact plugins will be broken by such change. If there is few such plugins we could make a switch to glib stdio. Also, we do not need fully overridable IO. We need a function that takes FILE* instead of file name. Adding such function (if it does not exist yet) is pretty trivial task and we could push such patch to upstream. Even if such change could not be performed we can simply convert file name from UTF-8 to what is used by real stdio. This leads to ugly code, but, again, if there is a few such plugins we could live with that. I'll find out what plugins need improvement in that area. There are also some dirty-hack solutions. We could hijack stdio funcs at compile time or link time to redirect them to glib stdio. This is commonly used to redirect malloc() and friends. ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
