On 2013/01/15 21:55, Denis Krjuchkov <de...@crazydev.net> wrote: > 16.01.2013 2:38, Max Kellermann ??????????: > >Hm, ok, I think wrapping everything in our own functions is not > >exactly the most beautiful solution, but will do. (It creates a third > >character set: UTF-8 for data/protocol strings, internal FS charset, > >external FS charset) > > Well I was thinking this way: external FS charset is really not > important for the most of the code. Let's consider this some > implementation detail for ustdio.cxx and Win32Util.cxx > The rest of the code could assume that FS charset is UTF-8.
What I would like to have in the long run is some compile-time verification on correct use. This is complicated enough already with just two different "string types", and I tried adding "_utf8" / "_fs" suffixes to variable names. Maybe some sort of C++ string wrapper that cannot be implicitly casted to the other wrapper. > You're right. I've started with changing all the functions to their > u_ counterparts. Then reverted some changes for the files that are > not to be compiled on Windows in a whole (such a daemonizing support > code). > > There are corner cases like in server_socket: some functions are to > be compiled on Windows but some are not. Do we need to use wrapper > in functions that are "ifndef WIN32" ? If some day such function > will became compilable on Windows somebody might easily forget to > add the prefix. This would introduce the bug. My complaint was not actually about POSIX-only code - it is ok to use u_* wrappers on non-portable code. My complaint was that the path name was not used consistently; one path string was passed to u_unlink(), and the very same pointer was copied without conversion to the sockaddr_un. Since it's impossible to use this consistently (because there's no "wide" sockaddr_un variant), I suggest not changing this, or adding a code comment explaining it, to aid the guy who happens to be porting this feature to Windows one day. > Some libraries can accept file descriptor or FILE*. > So we can pre-open such files for them using our u_ wrappers. > This requires some thinking how to avoid adding many new methods for > decoders (i.e. decoder_plugin_fd_decode, > decoder_plugin_FILE_decode). Extending the decoder API would not be necessary - each decoder plugin could implement the file_decode method and open the path_fs instead of passing it to the external library. ------------------------------------------------------------------------------ Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512 _______________________________________________ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
