> Because they know things will crash if they do
They will crash or do whatever undefined behaviour either way.
>Thats a specious argument. Since most programmers fix crashing errors that occur every time the program runs, the errors MUST depend on user input otherwise they would be fixed if they occurred all the time. So unless you apply analysis or exhaustive testing user input can always expose programming errors, so if the program can politely decline to perform the user operation and keep running its better than crashing.
No, these assertions are meant only for programming error, using them for release-build control flow is not advised. See from the docs below:
> The g_return family of macros (g_return_if_fail(), g_return_val_if_fail(), g_return_if_reached(), g_return_val_if_reached()) should only be used for programming errors, a typical use case is checking for invalid parameters at the beginning of a public function. They should not be used if you just mean "if (error) return", they should only be used if you mean "if (bug in program) return". The program behavior is generally considered undefined after one of these checks fails. They are not intended for normal control flow, only to give a perhaps-helpful warning before giving up.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/commit/109b8d079a59ba35e8aba5da960fc…
@b4n
> (although in practice most builders don't disable them anyway)
Because they know things will crash if they do :frowning:
> as these checks are for programming errors, and should not depend on user behavior.
Thats a specious argument. Since most programmers fix crashing errors that occur every time the program runs, the errors MUST depend on user input otherwise they would be fixed if they occurred all the time. So unless you apply analysis or exhaustive testing user input can always expose programming errors, so if the program can politely decline to perform the user operation and keep running its better than crashing.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/commit/109b8d079a59ba35e8aba5da960fc…
@elextr I find it pertinent to use these macros when they are meant to detect programming errors. Yes, you can be forcefully defensive and always check no matter the debugging status, but the point these macros can be disabled (although in practice most builders don't disable them anyway) is for one to be able to trade safety for more speed.
So IMO if a builder do want to disable those checks, fine, but they gotta know it's less defensive. Which could make sense, as these checks are for programming errors, and should not depend on user behavior.
In all cases, I think using a GError for programming error is worse than emitting a warning somewhere, because it's harder to handle the error and it could be ignored and left unnoticed more easily.
>Your documentation for the function doesn't disallow NULL
It odes, unless you accept `NULL` to be valid for *The project*, and as the function is supposed to save it to a file, I wouldn't expect `NULL` to be a valid one unless explicitly stated otherwise.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/commit/109b8d079a59ba35e8aba5da960fc…
The patch adds a new keybinding action for undoing hunks. When cursor is
placed at a line with a diff and the keybinding is invoked, the
corresponding hunk is undone.
To get the previous contents at the given position, a temporary Scintilla
instance is used into which the previous state of the document is loaded
and the corresponding text from the previous state of the document is
extracted. This temporary Scintilla object is then destroyed.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany-plugins/pull/531
-- Commit Summary --
* git-changebar: Add the possibility to undo hunk at cursor position
-- File Changes --
M git-changebar/src/gcb-plugin.c (135)
-- Patch Links --
https://github.com/geany/geany-plugins/pull/531.patchhttps://github.com/geany/geany-plugins/pull/531.diff
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/pull/531
Hmmm...yes I have also seen some calls like mine in other plugins. Let's say it this way: if never ever a programming error occurs than it is useless to check for ```NULL``` in this case. But whom am I to think that there never will be errors in the future? So I would always check pointers on the "boundaries" functions and just maybe not on internal static functions. In the case of an error it still prevents the user from a crash.
But for now I will keep the code like that. What about writing some own Geany debugging macros which use glib macros if compiled in and if not still guarantee an defined action and consistent error output among geany and geany plugins?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/commit/109b8d079a59ba35e8aba5da960fc…
Are you aware that its possible for distributions or others to build with G_DISABLE_CHECKS and the `g_return_val_if_failed` will be removed, so the function will crash on some poor user if their actions happen to result in the function being called with a NULL?
Your documentation for the function doesn't disallow NULL, so you always need to reject it. Probably better to use an if and `g_warning` or g_critical` for the message, which can be made to crash for easier debugging by setting G_DEBUG.
There have been some spirited Geany discussions about the "right" way to use these Glib debugging macros (IMHO there is none if the macro can be compiled out, unless you can prove by analysis or exhaustive testing that the failure cannot occur to the above mentioned innocent user, but if you can do that you don't need the test in the first place). Its certainly the case that Geany itself is still subject to the problem referred to above.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/commit/109b8d079a59ba35e8aba5da960fc…
I think it would make sense to give commander like search as you type interface for project organizer related `find file` and `find tags`. Say you show an entry box and as you type show the related list of objects and open file/with tags on `enter`
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/issues/599
1. create `test.c`, `test.h`, `directory/test.h`
2. open `test.c` and `directory/test.h`
3. from `test.c`, try switching to header
4. `directory/test.h` is switched to
it seems like this is using simple base filename checks and does not in any way check the path, so if there is a "matching" header from anywhere else on disk open then this will be used even when it is obviously (looking at paths) unrelated
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/issues/594