Glib docs note on `g_fopen()`:
"Because file descriptors are specific to the C library on Windows, and a file descriptor is part of the FILE struct, the FILE* returned by this function makes sense only to functions in the same C library. Thus if the GLib-using code uses a different C library than GLib does, the FILE* returned by this function cannot be passed to C library functions like fprintf() or fread()."
But it is passed to `fwrite()` by Geany.
I presume @eht16 ensures no C library problems when bundles are made, but anyone building it themselves may have an issue.
Should the `g_fopen()` be replaced by plain `fopen()`?
@eht16, Why was the `g_` version used in the first place since there is no matching `g_fwrite()`?
Why was the g_ version used in the first place since there is no matching g_fwrite()
It's to handle filenames uniformly I expect, for example on Windows to take a UTF-8 string for filename and mode and convert them to wide-char/UTF-8 like Windows uses normally. The [definition is here](https://git.gnome.org/browse/glib/tree/glib/gstdio.c#n713)
I don't there's an issue as the same C lib will be used in all supported configurations (mscvrt or glibc). It might be a problem if Geany `g_fopen`-ed a `FILE` and passed it to Scintilla, which uses a different C runtime (part of libstdc++ IIUC).
As @codebrainz said, it's to handle filename encoding implicitly. We could duplicate this (it's used in several places), even with just a mere copy to ensure it uses the same libc, but it should probably only be done if we find an actual issue with this. AFAIK we never got bitten by this, so I'd rather assess the actual possibilities before going ahead and copying some code over.
it's to handle filename encoding implicitly.
Ok, the "all windows are UTF-8" Glib standard I guess.
Like I said I'm sure @eht16 does it right for bundles, since glib and geany are compiled to use the same msys library.
I suppose we can just not worry about it until an issue occurs.
I presume @eht16 ensures no C library problems when bundles are made, but anyone building it themselves may have an issue.
Yes. The binaries and bundles provided by us should be fine as they(Geany, GLib, GTK, Scintilla) all built the same way and all uses the same C runtime provided by MSYS2. I'm pretty sure no code in Geany uses mscvrt at all when Geany is built as documented.
Of course, if anyone builds Geany with MSVC or manages to compile with gcc but link against mscvrt or something, then strange things will happen. I'd consider this as just not supported.
@eht16, Why was the `g_` version used in the first place since there is no matching `g_fwrite()`?
I'm afraid there was no deeper thinking about this but rather "hey, there is a g_ function for fopen(), so let's use this because it's probably better than the plain one as GLib does stuff for us". Today, I'd be rather not that naive but ten years ago, I was.
I'd consider this as just not supported.
Ok, closed
Closed #1271.
github-comments@lists.geany.org