GNOME Bugzilla – Bug 604682
Casting from string to uint8 results in huge memory allocation
Last modified: 2018-05-22 13:26:58 UTC
If I have something similar to the following: uint8[] str = (uint8[])"Hello World!\n"; valac generates a call to _vala_array_dup#, passing in -1 as the array length. This results in a g_memdup of (-1 * sizeof(guint8)), which will almost certainly fail. There should probably be a string length calculation in there.
Yep, manual casting of String to uint8[] doesn't work like it should. You have to use method String#to_utf8() to do that.
Strings have a .data property returning a byte array since Vala 0.9.5: uint8[] buffer = "Hello World!\n".data; Of course, this does not fix the casting bug.
I am tending to mark this invalid since assigning anything to an owned variable will require a ref/copy invocation. Therefore to avoid a copy it is required to do it like: unowned uint8[] str = (uint8[]) "Hello World!\n"; unowned uint8[] buffer = "Hello World!\n".data;
(In reply to Rico Tzschichholz from comment #3) > I am tending to mark this invalid since assigning anything to an owned > variable will require a ref/copy invocation. I don't think the bug should be marked as invalid. It is a reasonable thing to assume will work. If someone is expert in casting and ownership then maybe they will understand why they get problems at runtime, but that is not the Vala "vision" is it? If you mean Vala should report that the cast in invalid, then maybe. An error with a helpful message about using the .data property would probably be OK. After all in terms of outcome (uint8[]) "Hello World!\n!; is just an alternative syntax for "Hello World!\n".data; Ideally though I don't see a problem with supporting the two forms, but it is whether a technical solution for using g_strdup instead of g_memdup is easily implemented.
At the very least it seems sensible to report an error when the compiler can easily recognize that the code will not work. I expect it to be simple to reject g_memdup in cases where the array length has internally be set to -1. Or do you see any issue with this? Whether to properly set the array length for casts from string to uint8[] or not is an independent question. I can't think of a reason to keep -1 instead of calling strlen() out of the top of my head but maybe there was something that I fail to remember.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vala/issues/65.