[gstreamer-bugs] [Bug 350034] file{src, sink} don't convert to filesystem encoding

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=350034

  GStreamer | gstreamer (core) | Ver: HEAD CVS

Tim-Philipp Müller changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |t.i.m at zen.co.uk




------- Comment #20 from Tim-Philipp Müller  2008-03-12 11:48 UTC -------
Here's a log of a chat about this, which expands a bit on Edward's comments,
and which might clarify things a bit for those of us not so win32-savvy:

<tim> anyone win32-savvy around who could comment on whether
http://bugzilla.gnome.org/show_bug.cgi?id=350034#c19 is accurate? (hard to
believe, since it would defeat the purpose of g_open, or so it seem to me at
least)
<tm1> it is true
<tm1> the purpose of g_open() is to enable using Unicode filenames without
having to resort to UTF-16 (wchar_t), i.e. UTF-8
<tim> so one could only really use the fd returned by g_open() in connection
with iochannels then? Or how does one read/write/close them then?
<tm1> if one wanted to provide a GLib way around the different C runtime issue,
one would also need to wrap close(), read(), write(), fread(), fclose(),
popen() etc etc, i.e. all C functions that use file descriptors, including thos
that use FILE *
<tm1> if the code that calls g_open() uses the same C runtime as GLib, then it
can use the returned file descriptor normally
<tm1> if it uses another C runtime, then it can't
<tim> ah
<tm1> that's why gcc and MSVC6 (!) are the preferred compilers for GLib-using
code on Windows
<tim> is there a way to check that somehow (at runtime)?
<tm1> umm, probably, but the person who builds something really should knw what
he/she is doing ;)
<tim> hmm, yes, but I'd feel more comfortable if it was possible to just error
out with a big fat "your build is broken, go fix it" :)
<tm1> well, not all apps necessarily use those APIs that cause problms, those
work fine even if they use a different runtime
<tm1> but yeah, this is a mess..
<tm1> feel free to post my comments to the bug report
<tim> thanks
<tm1> I guess there is also always room for improvements to the documentation,
things like this maybe need to be pointed out more explicitly
<tim> got a suggestion on what the best thing to do is if we want to allow
people to build things with newer MSVCs too?
<tm1> well, one possibility would be to build glib and gtk+ with that MSVC too,
then
<tm1> but when doing that, please then make sure to use different names for the
DLLs to avoid potential mixup 
<tim> well, random people will build it and ship stuff, I don't think that's
something that's going to be easy to enforce
<tm1> unfortunately it isn't really easy to build glib or gtk+ with MSVC. there
are some "makefile.msc" files for nmake, but they require manual editing. they
are maintaned by Hans Breuer
<tim> what's the alternative? Do the utf8=>utf16 conversion ourselves and use
the utf16 functions directly with #ifdefs? would that work?
<tm1> glib has some VS8 project files in build/win32/vs8
<tm1> that is quite possible, sure
<tm1> but then those fds from your app can't be passed to glib APIs that take
file descriptors, like g_io_channel_win32_new_fd()


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=350034.