It would be convenient to append items "copy filename" and "copy filepath" on tabs right click menu
---
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/868
`foreach_ptr_array()` was reading one element past the end of the array. This was not usually noticeable because the resulting garbage pointer was not actually used, and it's highly unlikely there is protected or foreign memory right after the array, but there is actually no such guarantee, and it's bad nonetheless.
This actually resulted in Valgrind complaining, and hence me noticing:
==1217514== Invalid read of size 8
==1217514== at 0x49120B9: keyfile_action (stash.c:271)
==1217514== by 0x49130BB: stash_group_load_from_key_file (stash.c:308)
==1217514== by 0x48F179D: settings_action (keyfile.c:396)
==1217514== by 0x48F2D5E: read_config_file (keyfile.c:1245)
==1217514== by 0x48F3FAB: configuration_load (keyfile.c:1278)
==1217514== by 0x48F5393: load_settings (libmain.c:917)
==1217514== by 0x48F667F: main_lib (libmain.c:1154)
==1217514== by 0x109141: main (main.c:27)
==1217514== Address 0x910a3f0 is 0 bytes after a block of size 16 alloc'd
==1217514== at 0x48406C4: malloc (vg_replace_malloc.c:380)
==1217514== by 0x5B2C717: g_realloc (gmem.c:201)
==1217514== by 0x5AF2AA3: g_ptr_array_maybe_expand (garray.c:1640)
==1217514== by 0x5AF4066: g_ptr_array_add (garray.c:1962)
==1217514== by 0x4912247: add_pref (stash.c:491)
==1217514== by 0x491331E: stash_group_add_integer (stash.c:531)
==1217514== by 0x48F3857: init_pref_groups (keyfile.c:339)
==1217514== by 0x48F42A1: configuration_init (keyfile.c:1500)
==1217514== by 0x48F6661: main_lib (libmain.c:1146)
==1217514== by 0x109141: main (main.c:27)
==1217514==
or:
==1217514== Invalid read of size 8
==1217514== at 0x48EA315: keybindings_foreach (keybindings.c:768)
==1217514== by 0x48EC9B4: load_user_kb (keybindings.c:817)
==1217514== by 0x48EFBDC: keybindings_load_keyfile (keybindings.c:846)
==1217514== by 0x48F6756: main_lib (libmain.c:1206)
==1217514== by 0x109141: main (main.c:27)
==1217514== Address 0xd570830 is 0 bytes after a block of size 32 alloc'd
==1217514== at 0x484582F: realloc (vg_replace_malloc.c:1437)
==1217514== by 0x5B2C717: g_realloc (gmem.c:201)
==1217514== by 0x5AF2AA3: g_ptr_array_maybe_expand (garray.c:1640)
==1217514== by 0x5AF4066: g_ptr_array_add (garray.c:1962)
==1217514== by 0x48ECC43: keybindings_set_item (keybindings.c:180)
==1217514== by 0x48ECD92: add_kb (keybindings.c:295)
==1217514== by 0x48EE686: init_default_kb (keybindings.c:518)
==1217514== by 0x48EFB7C: keybindings_init (keybindings.c:751)
==1217514== by 0x48F6698: main_lib (libmain.c:1160)
==1217514== by 0x109141: main (main.c:27)
The problematic code was setting the new value for the item pointer after incrementing the index, but before validating it was still in the valid range.
Fix this by moving the item assignment in the condition expression. This requires using a comma operator and a logical AND to make sure the expression does not contribute to the test (allowing e.g. NULL values) yet being dependent on the index validation passing.
Note that this change, as implemented here, slightly affects behavior: `item` will point to the last *actual* node of the array (not out of bounds) after the loop, but also it will not be set at all if the array has no items. Before this change, the value was NULL for no items, and garbage otherwise.
As the value after the loop was effectively only usable for empty arrays, it sounds safe enough to assume no caller depended on an empty array leading to initializing `item`, so we can drop this special case. And unsurprisingly no caller in Geany itself depend on that.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3536
-- Commit Summary --
* Fix out-of-bounds read in foreach_ptr_array()
-- File Changes --
M src/utils.h (3)
-- Patch Links --
https://github.com/geany/geany/pull/3536.patchhttps://github.com/geany/geany/pull/3536.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3536
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3536(a)github.com>
After the update to Scintilla 5.1.5, I started getting memory corruption crashes when saving some files. (Sorry for not noticing this before, I thought the Scintilla update didn't contain any changes on the Geany side.) I may be wrong but I think the problem is in
https://github.com/geany/geany/pull/3046/commits/d7c985e47412f8a53c5a8202a0…
and misunderstanding if the following Scintilla API change
>When calling SCI_GETTEXT, SCI_GETSELTEXT, and SCI_GETCURLINE with a NULL buffer argument to discover the length that should be allocated, do not include the terminating NUL in the returned value. The value returned is 1 less than previous versions of Scintilla. Applications should allocate a buffer 1 more than this to accommodate the NUL. The wParam (length) argument to SCI_GETTEXT and SCI_GETCURLINE also omits the NUL. This is more consistent with other APIs.
This part
>When calling SCI_GETTEXT, SCI_GETSELTEXT, and SCI_GETCURLINE with a NULL buffer argument to discover the length that should be allocated, do not include the terminating NUL in the returned value...
> ...The wParam (length) argument to SCI_GETTEXT and SCI_GETCURLINE also omits the NUL.
says that that the returned __length__ doesn't include NUL, not that the returned string misses the NUL character. The rest of the change description says that we should allocate `+1` buffer to accommodate for that.
I believe we should revert the above patch and then go through all the uses of `SCI_GETTEXT`, `SCI_GETSELTEXT`, and `SCI_GETCURLINE` and corresponding `sci_` wrappers and update the code where needed (including plugins). I don't think it's a good idea to update the `sci_` wrappers alone to mirror previous behavior since the whole Scintilla API is part of Geany's API so this is a API change anyway and making `sci_` functions do something else than direct Scintilla calls is confusing.
Rant: I really don't understand why Neil made this change - even though it fixes some inconsistency in Scintilla API, this is a hard to spot backwards incompatible change and such things shouldn't be made in minor releases of a library.
@kugel- @eht16 @elextr What do you think?
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3095
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3095(a)github.com>
This is to mitigate this change in Scintilla 5.1.5:
> When calling SCI_GETTEXT, SCI_GETSELTEXT, and SCI_GETCURLINE with a NULL buffer argument to discover the length that should be allocated, do not include the terminating NUL in the returned value. The value returned is 1 less than previous versions of Scintilla. Applications should allocate a buffer 1 more than this to accommodate the NUL. The wParam (length) argument to SCI_GETTEXT and SCI_GETCURLINE also omits the NUL. This is more consistent with other APIs.
While it doesn't prevent simple recompilation of existing plugins without fixing the possible problems in them, at least it doesn't allow users using binary releases to load old, unfixed plugins.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/3541
-- Commit Summary --
* Bump Geany ABI to mitigate Scintilla 5.1.5 changes
-- File Changes --
M src/plugindata.h (2)
-- Patch Links --
https://github.com/geany/geany/pull/3541.patchhttps://github.com/geany/geany/pull/3541.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3541
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/pull/3541(a)github.com>
Unless I am wrong, should not "%Y-%m-%d" be the first of the formats offered and not as a special format.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3556
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3556(a)github.com>
Would it be possible to group the color themes into "light" and "dark"? Either as two columns in the theme selector or as two sections in the list.
Background: Lately I've been getting irritated eyes frequently and was suggested that this may be due to staring at a bright screen for extended periods of time, so (in addition to adjusting the brightness) I decided to give dark themes a try, since I heard they are less harmful for your eyes (not sure how scientific this is, but trying won't hurt...)
Problem is, it was hard to compare dark themes by going through the list with arrow keys, because light and dark are interleaved, and whenever I hit a light theme my eyes would readjust and forget if the previous dark theme was better or worse than the next.
So I think being able to browse only light or only dark themes would make the choice easier.
(This leaves open the question: "how do you decide if a theme is light or dark automatically?" -- I guess probably looking at the default background and foreground colors, but comparing color brightness is a bit tricky...)
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3566
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3566(a)github.com>
Hi,
i am using Debian 12 and Geany 1.38 for Python 3 programming. I use Cinnamon Desktop; However the issue persists in both Cinnamon and GNOME Desktop environments.
1. Set build Commands:
a) "Compile" is set to: **python3 -m py_compile "%f"**
b) "Execute" is set to: **python3 "%f"**
c) "Make", Make Custom Target each set to: **make**
d) "Make Object" is set to: **make %e.o**
2. Edit --> Preferences -->Tools:
a) Terminal is set to: **x-terminal-emulator -e "/bin/sh %c"**
b) Browser is set to: **sensible-browser**
c) Grep is set to: grep
**Issue**:on hitting F5 to execute/run code results in a terminal window popup launching and disappearing almost instantly. Will appreciate help with resolving the issue.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/3567
You are receiving this because you are subscribed to this thread.
Message ID: <geany/geany/issues/3567(a)github.com>