vala issueshttps://gitlab.gnome.org/GNOME/vala/-/issues2024-03-04T10:26:51Zhttps://gitlab.gnome.org/GNOME/vala/-/issues/1529Incompatible pointer sign type for Socket.receive/send (uint8 vs. char)2024-03-04T10:26:51ZMartin PittIncompatible pointer sign type for Socket.receive/send (uint8 vs. char)[Socket.receive()](https://valadoc.org/gio-2.0/GLib.Socket.receive.html) declares its `buf` argument as `uint8[]`. But the underlying [g_socket_receive()](https://docs.gtk.org/gio/method.Socket.receive.html) declares it as `gchar*`, whic...[Socket.receive()](https://valadoc.org/gio-2.0/GLib.Socket.receive.html) declares its `buf` argument as `uint8[]`. But the underlying [g_socket_receive()](https://docs.gtk.org/gio/method.Socket.receive.html) declares it as `gchar*`, which is signed by default. This causes compiler warnings like
```
./../source/tests/test-umockdev-record.vala:698:36: error: pointer targets in passing argument 2 of ‘g_socket_receive’ differ in signedness [-Werror=pointer-sign]
698 | ssize_t len = conn.receive (buf);
| ^~~~~~
| |
| guint8 * {aka unsigned char *}
/usr/include/glib-2.0/gio/gsocket.h:209:83: note: expected ‘gchar *’ {aka ‘char *’} but argument is of type ‘guint8 *’ {aka ‘unsigned char *’}
```
The same happens for [Socket.send()](https://docs.gtk.org/gio/method.Socket.send.html).
Declaring the buffer as `char[]` in Vala makes things worse:
```
../../source/tests/test-umockdev-record.vala:714.44-714.46: error: Argument 3: Cannot convert from `unowned uint8[]' to `unowned char[]'
714 | len = read_buf_delay (20000, conn, buf, 6);
| ^~~
```
Note: I report this so late as until recently, meson hid all C compiler warnings generated from Vala code. But that [changed recently](https://github.com/mesonbuild/meson/pull/12597).0.58https://gitlab.gnome.org/GNOME/vala/-/issues/1465HashTable.insert(), HashTable.replace() and GenericSet.add() should return bool2023-08-03T11:28:48ZNanling Zhengneithern@outlook.comHashTable.insert(), HashTable.replace() and GenericSet.add() should return boolStarting from GLib 2.40, these functions return a boolean value to indicate whether the newly added value was already in the hash table or not.
Thanks!Starting from GLib 2.40, these functions return a boolean value to indicate whether the newly added value was already in the hash table or not.
Thanks!0.58https://gitlab.gnome.org/GNOME/vala/-/issues/1454Throws FileStream2023-07-15T13:41:50ZHydral Nathan JordanThrows FileStreamAdd functions such as try_open(), try_fdopen() like this
```vala
[CCode (cname = "g_fopen", cheader_filename = "glib/gstdio.h")]
public static FileStream? open (string path, string mode);
[CCode (cname = "fdopen")]
public static FileSt...Add functions such as try_open(), try_fdopen() like this
```vala
[CCode (cname = "g_fopen", cheader_filename = "glib/gstdio.h")]
public static FileStream? open (string path, string mode);
[CCode (cname = "fdopen")]
public static FileStream? fdopen (int fildes, string mode);
public static FileStream? try_open (string path, string mode) throws GLib.FileError {
FileStream fs = open(path, mode);
if (fs == null || fs.error () != 0) {
throw new FileError.ACCES ("Can't acces to file");
}
return fs;
}
public static FileStream? try_fdopen (int fildes, string mode) throws GLib.FileError {
FileStream fs = fdopen(fildes, mode);
if (fs == null || fs.error () != 0) {
throw new FileError.ACCES ("Can't acces to file");
}
return fs;
}
```
and do it on all the other functions, do you think it's a good idea? if it's enough I can carry on :smile:https://gitlab.gnome.org/GNOME/vala/-/issues/1452The many issues of GLib.Datalist2023-11-29T04:05:03ZVal Ochv19930312@gmail.comThe many issues of GLib.DatalistI wanted to use GLib.Datalist in one of my programs, but it turned out to be rather broken when used from Vala.
# Direct issues I've encountered
Let's go with this simple program:
```vala
void my_inserter(Datalist<string> dlist) {
...I wanted to use GLib.Datalist in one of my programs, but it turned out to be rather broken when used from Vala.
# Direct issues I've encountered
Let's go with this simple program:
```vala
void my_inserter(Datalist<string> dlist) {
dlist.set_data("good", "day");
}
int main() {
var dlist = new Datalist<string>();
dlist.set_data("hello", "world");
my_inserter(dlist);
print("Listing results:\n");
dlist.foreach((quark, data) => {
print("%s %s\n", quark.to_string(), data);
});
return 0;
}
```
How many problems are there? At very least three, one of them very serious!
## Memory corruption due to access from function
I'm not *quite* sure why this happens, but appending to datalist in `my_inserter` leads to memory corruption logged by valgdrind and quite possibly segfault. Using `ref` argument seemingly solves the problem, but this remains a very viable method to shoot yourself in your foot by merely passing a structure to a function and getting no compiler warnings.
## Datalist itself is never freed
It's not very clear from documentation, but you need to release datalist contents by calling `g_datalist_clear` as its destructor. Trivial to fix - just annotate Datalist with `[CCode (destroy_function = "g_datalist_clear")]`.
## Even with fix above strings are leaked anyways
This is because `set_data` assumes that no freeing is needed (i.e. performs no ownership transfer) while its argument annotation points to the contrary. I've tried to annotate method in question as
```vala
[CCode (cname = "g_datalist_set_data_full", simple_generics = true)]
public void set_data (string key, owned G data);
```
...which should just work as intended from what I read, but this led to Vala compiler bailing out from somewhere deep inside and I'm not up to the task of debugging that.
As a side note, it might be useful to keep unowning setter, although it probably should not be the default one (`set_data_unowned`?). Finally, all in this section also applies to quark version of this function, `id_set_data`.
# Even more issues to ponder
## `id_replace_data` should probably just be dropped from binding
It has complex ownership management semantics that Vala simply does not support. Worse yet, they are conditional - that is, you need to check its return value to know which value you own and which you do not.
## Accessors and `DuplicateFunc` should use nullable types
This includes both argument and return value of `DuplicateFunc` delegate and return values of methods `id_dup_data`, `id_get_data`, `id_remove_no_notify`, `get_data`, `remove_no_notify`.
## Finally - should Datalist itself be a generic? Or only its member functions?
Datalist allows you to store multiple different types in it by design, so treating it as storing only a single type only *sometimes* makes sense (notably in its use in libsoup, where keys are expected to be strings). It might be a good idea to introduce another type (kind of like `GenericSet` for `HashTable`) that would have member functions take generic argument rather than class itself. Although I'm not sure what `foreach` function would look like in such implementation...https://gitlab.gnome.org/GNOME/vala/-/issues/1447Most of GLib.ActionGroup should be virtual instead of abstract.2023-06-26T08:27:24ZGustavo MarquesMost of GLib.ActionGroup should be virtual instead of abstract.Currently the gio metadata only mark query_action as virtual, but in fact, the true abstract methods are activate_action, change_action_state, and list_action. all the rest should be marked as virtual too.Currently the gio metadata only mark query_action as virtual, but in fact, the true abstract methods are activate_action, change_action_state, and list_action. all the rest should be marked as virtual too.0.58https://gitlab.gnome.org/GNOME/vala/-/issues/1446GLib.SourceOnceFunc should return void type2023-06-26T08:27:24ZNanling Zhengneithern@outlook.comGLib.SourceOnceFunc should return void typeGLib.SourceOnceFunc should return void type, but current it return bool type.GLib.SourceOnceFunc should return void type, but current it return bool type.0.58https://gitlab.gnome.org/GNOME/vala/-/issues/1402Enhancement: improve the performance of `string.split` and enable to set maxi...2023-02-22T02:47:08ZZhou Qiankang (周 乾康)wszqkzqk@qq.comEnhancement: improve the performance of `string.split` and enable to set maximum of piecesNow the implementation of `string.split` will compile a new regex object every time it called. This may be of low performance. Could we use `string.split` and `string.joinv` to implement instead? And then we can enable to set maximum of ...Now the implementation of `string.split` will compile a new regex object every time it called. This may be of low performance. Could we use `string.split` and `string.joinv` to implement instead? And then we can enable to set maximum of pieces without breaking existing things.0.58https://gitlab.gnome.org/GNOME/vala/-/issues/1354Unicode encode bug when running `stdin.readline()` in Windows2022-09-01T16:36:03ZZhou Qiankang (周 乾康)wszqkzqk@qq.comUnicode encode bug when running `stdin.readline()` in WindowsFor example:
```vala
void main()
{
Intl.setlocale(LocaleCategory.ALL, "");
var info = stdin.read_line ();
print(info);
}
```
When typing unicode strings, the output is wrong:
```pwsh
> example.exe
> Hello, world! 你好,世界!
```
...For example:
```vala
void main()
{
Intl.setlocale(LocaleCategory.ALL, "");
var info = stdin.read_line ();
print(info);
}
```
When typing unicode strings, the output is wrong:
```pwsh
> example.exe
> Hello, world! 你好,世界!
```
And the output is:
```
Hello, world!
```
The unicode characters are disappeared.https://gitlab.gnome.org/GNOME/vala/-/issues/1350Add binding for g_abort()2022-09-12T19:23:15ZBenAdd binding for g_abort()0.58https://gitlab.gnome.org/GNOME/vala/-/issues/1327GLib.Date missing the constructors2022-06-01T18:09:36ZTAO ZUHONGGLib.Date missing the constructors[Date @ Valadoc.org](https://valadoc.org/glib-2.0/GLib.Date.html)<br/>
[Date @ docs.gtk.org](https://docs.gtk.org/glib/struct.Date.html)<br/>
![image](/uploads/971184f7fa79b8dad845c42788499b70/image.png)[Date @ Valadoc.org](https://valadoc.org/glib-2.0/GLib.Date.html)<br/>
[Date @ docs.gtk.org](https://docs.gtk.org/glib/struct.Date.html)<br/>
![image](/uploads/971184f7fa79b8dad845c42788499b70/image.png)https://gitlab.gnome.org/GNOME/vala/-/issues/1295GTestSuite destroy methods in 2.70 cause double free2022-09-12T19:17:15ZMichael TerryGTestSuite destroy methods in 2.70 cause double freeHello! Here is a sample reproduction program:
```
int main(string[] args)
{
Test.init(ref args);
var suite = new TestSuite("suite");
TestSuite.get_root().add_suite(suite);
return Test.run();
}
```
With `valac`, the following is...Hello! Here is a sample reproduction program:
```
int main(string[] args)
{
Test.init(ref args);
var suite = new TestSuite("suite");
TestSuite.get_root().add_suite(suite);
return Test.run();
}
```
With `valac`, the following is generated and everything works fine:
```
_tmp0_ = g_test_create_suite ("suite");
suite = _tmp0_;
_tmp1_ = g_test_get_root ();
g_test_suite_add_suite (_tmp1_, suite);
result = g_test_run ();
```
With `valac --target-glib=2.70`, the following is generated and you get a bad free inside of g_test_run.
```
_tmp0_ = g_test_create_suite ("suite");
suite = _tmp0_;
_tmp1_ = g_test_get_root ();
_tmp2_ = _tmp1_;
g_test_suite_add_suite (_tmp2_, suite);
_g_test_suite_free0 (_tmp2_);
result = g_test_run ();
_g_test_suite_free0 (suite);
```0.56https://gitlab.gnome.org/GNOME/vala/-/issues/1271MemoryOutputStream's construction should not dupe array2023-07-11T06:54:19ZVal Ochv19930312@gmail.comMemoryOutputStream's construction should not dupe arrayI'd like to use MemoryOutputStream with fixed-sized buffer. However, this currently fails:
```Vala
int main() {
uint8 outbuf[1] = {0};
{
var mem_stream = new MemoryOutputStream(outbuf, null, null);
var ostr = new DataOutputStream(...I'd like to use MemoryOutputStream with fixed-sized buffer. However, this currently fails:
```Vala
int main() {
uint8 outbuf[1] = {0};
{
var mem_stream = new MemoryOutputStream(outbuf, null, null);
var ostr = new DataOutputStream(mem_stream);
ostr.put_byte('H');
}
assert(outbuf[0] == 'H');
return 0;
}
```
Reading source code (or running with Valgrind) reveals that Vala silently makes a copy of array:
```C
_tmp1_ = _vala_array_dup1 (outbuf, 1);
_tmp1__length1 = 1;
_tmp2_ = (GMemoryOutputStream*) g_memory_output_stream_new (_tmp1_, _tmp1__length1, NULL, NULL);
```
I'm guessing this is caused by `owned` annotation of array in [`MemoryOutputStream`'s constructor](https://valadoc.org/gio-2.0/GLib.MemoryOutputStream.MemoryOutputStream.html), which seems like a mistake to me. Removing `owned` annotation by hand indeed makes provided example work as intended.
P.S.: this is also the case for `MemoryInputStream`, but there it "only" results in silent memory leak instead of major logic error.
Using Vala 0.54.5.0.56https://gitlab.gnome.org/GNOME/vala/-/issues/1238Memleak when removing GLib.Object from list2021-10-19T08:00:21ZDaniel BrendleMemleak when removing GLib.Object from listThe following code will produce a memory leak in Vala 0.48.18 and Vala 0.54.2
Expected behaviour:
As the swag object inside the test method goes out of scope and it is not referenced by the list anymore, it should be freed.
Actual ...The following code will produce a memory leak in Vala 0.48.18 and Vala 0.54.2
Expected behaviour:
As the swag object inside the test method goes out of scope and it is not referenced by the list anymore, it should be freed.
Actual behaviour:
The object is not being freed
This also works when placing the whole content of `void test()` in the main method
```
public class Swag : GLib.Object {
public Swag() {
message("maded a swag");
}
~Swag() {
message("destructerizered a swag");
}
}
public static void test() {
var list = new GLib.List<Swag>();
var swag = new Swag();
list.append(swag);
list.remove(swag);
}
public static void main (string[] argv) {
test();
}
```0.56https://gitlab.gnome.org/GNOME/vala/-/issues/1222GLib.SettingsBackend.get_permission method definition missing from gio-2.0.vapi.2021-09-23T08:30:07ZTheMusoGLib.SettingsBackend.get_permission method definition missing from gio-2.0.vapi.The abstract class SettingsBackend definition in gio-2.0.vapi is missing g_settings_backend_get_permission. If present, it would be:
`public virtual GLib.Permission get_permission (string path);`
I am using vala 0.48.18 on Fedora 34, h...The abstract class SettingsBackend definition in gio-2.0.vapi is missing g_settings_backend_get_permission. If present, it would be:
`public virtual GLib.Permission get_permission (string path);`
I am using vala 0.48.18 on Fedora 34, however vala git master does not have the definition for this either. From looking at the gio code and headers, this method is public.
Thanks.0.54https://gitlab.gnome.org/GNOME/vala/-/issues/1220bindings issue2022-09-08T14:06:34ZAli Galalbindings issue## ‘G_PI’ undeclared (first use in this function); did you mean ‘M_PI’? <br>
![Screenshot_from_2021-08-29_22-32-15](/uploads/cfb2ae8b44a0da87d381afa62a82d155/Screenshot_from_2021-08-29_22-32-15.png)## ‘G_PI’ undeclared (first use in this function); did you mean ‘M_PI’? <br>
![Screenshot_from_2021-08-29_22-32-15](/uploads/cfb2ae8b44a0da87d381afa62a82d155/Screenshot_from_2021-08-29_22-32-15.png)0.54https://gitlab.gnome.org/GNOME/vala/-/issues/1190glib-2.0.vapi: GLib.List.next / GLib.List.prev should be nullable2021-06-02T12:26:39ZPrinceton Ferroglib-2.0.vapi: GLib.List.next / GLib.List.prev should be nullablehttps://gitlab.gnome.org/GNOME/vala/-/issues/1087Think about merging back GLib.GenericArray into GLib.PtrArray2020-10-17T16:21:05ZCorentin NoëlThink about merging back GLib.GenericArray into GLib.PtrArrayThe current GLib.PtrArray implementation isn't really working and is deprecated since a long time.
It would be great to merge back GLib.GenericArray into GLib.PtrArray.
We should make sure that no code is using GLib.PtrArray anymore.The current GLib.PtrArray implementation isn't really working and is deprecated since a long time.
It would be great to merge back GLib.GenericArray into GLib.PtrArray.
We should make sure that no code is using GLib.PtrArray anymore.https://gitlab.gnome.org/GNOME/vala/-/issues/1085How to tell whether Stat constructor worked?2020-10-15T10:21:58ZReuben ThomasHow to tell whether Stat constructor worked?This looks like it could be a bug in the binding, but maybe there's just something missing in the docs: `g_stat` returns an int indicating success or failure, but I can't see any way in `glib-2.0.vapi` that the success or failure is sign...This looks like it could be a bug in the binding, but maybe there's just something missing in the docs: `g_stat` returns an int indicating success or failure, but I can't see any way in `glib-2.0.vapi` that the success or failure is signalled: the return code seems to be discarded.
If there is a way to determine success or failure, please could it be documented?https://gitlab.gnome.org/GNOME/vala/-/issues/1054gio-2.0.vapi contains bad bindings for GLib.SettingsBackend2020-08-10T13:45:56ZJonathan Moermangio-2.0.vapi contains bad bindings for GLib.SettingsBackendThe definitions for SettingsBackend are included in `gio/gsettingsbackend.h` while `gio-2.0.vapi` contains:
```
[CCode (cheader_filename = "gio/gio.h", type_id = "g_settings_backend_get_type ()")]
public abstract class SettingsBackend : ...The definitions for SettingsBackend are included in `gio/gsettingsbackend.h` while `gio-2.0.vapi` contains:
```
[CCode (cheader_filename = "gio/gio.h", type_id = "g_settings_backend_get_type ()")]
public abstract class SettingsBackend : GLib.Object {
...
}
```
`gio/gio.h` does **not** cause `gio/gsettingsbackend.h` to be included.
With the current bindings the C compiler outputs warnings like `implicit declaration of function ‘g_keyfile_settings_backend_new’; did you mean ‘some_other_function’?` and generated code causes segfaults.
Replacing all `gio/gio.h` occurences with `gio/gsettingsbackend.h` here fixes this issue. Also see https://developer.gnome.org/gio/stable/GSettingsBackend.html
edit: just replacing `gio/gio.h` occurences with `gio/gsettingsbackend.h` for SettingsBackend isn't a good solution as `gio/gsettingsbackend.h` then also gets included even when none of the functions of SettingsBackend get used.0.50https://gitlab.gnome.org/GNOME/vala/-/issues/1052Bad binding for g_unix_mounts_for2020-08-10T13:45:56ZMichael TerryBad binding for g_unix_mounts_forI believe the binding for `g_unix_mounts_for` is incorrect. (That method does not actually exist in glib.)
Trying to use it (`UnixMountEntry.@for`) results in: `undefined reference to g_unix_mounts_for`
The binding currently looks like...I believe the binding for `g_unix_mounts_for` is incorrect. (That method does not actually exist in glib.)
Trying to use it (`UnixMountEntry.@for`) results in: `undefined reference to g_unix_mounts_for`
The binding currently looks like:
```
[CCode (cname = "g_unix_mounts_for")]
[Version (since = "2.52")]
public static GLib.List<GLib.UnixMountEntry> @for (string file_path, out uint64 time_read = null);
```
But should look like:
```
[CCode (cname = "g_unix_mount_for")]
[Version (since = "2.52")]
public static GLib.UnixMountEntry @for (string file_path, out uint64 time_read = null);
```
(that is, singular function name and only returns a single instance)
See docs at https://developer.gnome.org/gio/stable/gio-Unix-Mounts.html#g-unix-mount-for0.48