Especially under Windows, there are 32-bit and 64-bit stat, and g_[l]stat may use the non-default one. You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/677
-- Commit Summary --
* g_[l]stat require a GStatBuf argument, not struct stat
-- File Changes --
M src/dialogs.c (2) M src/document.c (6) M src/socket.c (2) M tagmanager/ctags/ctags.c (18) M tagmanager/src/tm_source_file.c (4) M tagmanager/src/tm_workspace.c (2)
-- Patch Links --
https://github.com/geany/geany/pull/677.patch https://github.com/geany/geany/pull/677.diff
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/677
@@ -49,6 +49,7 @@
+#ifndef GLIB_MAJOR_VERSION
Does this hurt now we are using GStatBuf and g_(l)stat()?
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/677/files#r41202128
Good catch!
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/677#issuecomment-145677775
Except for that line where @elextr commented, it looks good to me.
As a separate PR we could probably remove the inconsistently guarded `sys/types.h` usage and replace with GLib typedefs as well.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/677#issuecomment-145713433
@@ -49,6 +49,7 @@
+#ifndef GLIB_MAJOR_VERSION
IIUC `GLIB_MAJOR_VERSION` will always be defined, and if not, there will be a compilation (preprocessor) error much earlier where we unconditionally include `glib.h`.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/677/files#r41217126
Except for that line where @elextr commented, it looks good to me.
Same.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/677#issuecomment-145844886
@@ -49,6 +49,7 @@
+#ifndef GLIB_MAJOR_VERSION
I was about to delete the entire block, but ctags.c also contains checks for AMIGA, __EMX__, MS-DOS, QDOS and whatnot, so how much deletion would be enough?.. Since there are several #if 0 blocks, I decided to put this one in an #ifndef which will both exclude it from compilation and signify why.
It doesn't really matter if the block will be deleted (though there are others which deserve deletion much more), or excluded with #if 0, or something else, so please say what you consider the right thing. After daf4dd45b874f7d29e30f8eddd4fbb6cae40e687 was applied, this PR is conflicting, so I'll have to modify or recreate it anyway.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/677/files#r41292605
@elextr
Good catch!
Well, not exactly. I had spurious reload prompts from a long time with MinGW (no MSYS), but was too lazy to check why - turns out, the high 32 bits of st_mtime were sometimes non-zero (no idea why the 64-bit stat was used). Then MSYS2 gcc complained outright that the pointer type passed to g_stat() is wrong, so it was hard not to notice it. :)
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/677#issuecomment-145932401
@@ -49,6 +49,7 @@
+#ifndef GLIB_MAJOR_VERSION
I'm all for deleting as much code as possible :) If the block is left, IMO it should be changed to `#if 0` since it's obvious that it's more like a comment, whereas using `GLIB_MAJOR_VERSION` is kind of confusing.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/677/files#r41337184
@@ -49,6 +49,7 @@
+#ifndef GLIB_MAJOR_VERSION
Are we ever going to exchange ctags.c with upstream? I doubt it, it now has lots of changes. So I guess it won't hurt to change it some more by deleting stuff. But that should be its own PR.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/677/files#r41337848
At this point, I need exact instructions of how to change the PR by someone willing to apply it, rather than opinions. Also, it's currently conflicting, and I remember a discussion about keeping the ChangeLog clean by not merging...
Whoever has write access to the Geany repository, can't you please spare a few minutes to get a fresh copy, Find in Files "struct stat", replace it with GStatBuf and commit? It's as simple as that. You don't even need to touch the ctags.c block discussed above, it's not conflicting if you leave it as is.
(No, I don't care that the change will be attributes to someone else. What's important to me is to have a working Geany without local patches I need to apply each time.)
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/677#issuecomment-146270656
Closed #677 via d6e94cf9d4b41b55f06bafe185b1b0a7fc61bd30.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/677#event-429770599
I rebased it on master, fixed the merge conflicts and tweaked the commit message a bit.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/677#issuecomment-146376191
If anyone remembers, we should probably cleanup that part that was guarded out before and the other blocks mentioned, as well the mixed use of guarded and non-guarded includes of sys/types.h and such, which probably could be replaced by GLib types as well (ex. goffset, etc).
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/677#issuecomment-146377152
@codebrainz
Thank you.
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/pull/677#issuecomment-146593447
github-comments@lists.geany.org