3 ms·

Why instantly crash when out of memory instead of letting caller decide what to do? Also, some GString methods that have string length argument do not append N

Why instantly crash when out of memory instead of letting caller decide what to do? Also, some GString methods that have string length argument do not append NUL terminator, assuming that the input string is terminated at length+1. This could lead to fun buffer overrun if the string is to be used by functions expecting C-strings. I guess they are to be used when strlen is known by caller, but nevertheless, some documentation would help.

aheck 4y ago
You're right, calling exit when out of memory is at least controversial if not even bad. I still do it because the goal is to be source compatible with GLib. And this is how GLib handles out of memory, unfortunately. https://libsoup.org/glib/glib-Memory-Allocation.html#g-malloc https://libsoup.org/glib/glib-Memory-Allocation.html#g-mallo... https://stackoverflow.com/questions/16974254/glib-handle-out-of-memory https://stackoverflow.com/questions/16974254/glib-handle-out... Thanks for pointing out the null termination issue. This was actually a bug and I just fixed it in g_string_append_len. The other _len methods look fine to me. Since CLib aims to be source compatible with GLib the documentation for the respective classes of GLib should do it: https://libsoup.org/glib/glib-Strings.html https://libsoup.org/glib/glib-Strings.html https://libsoup.org/glib/glib-Hash-Tables.html https://libsoup.org/glib/glib-Hash-Tables.html https://libsoup.org/glib/glib-Doubly-Linked-Lists.html https://libsoup.org/glib/glib-Doubly-Linked-Lists.html
- andrewmcwatters 4y ago
  I had no idea GLib did that. Their string implementation seems to be the best one to use, too, for those looking for a capacity, length, and data implementation. I'm a bit disappointed to know this now. But good on you for being strictly compatible; I feel like many people would fudge the implementation. Thanks for sharing this.
  - aheck 4y ago
    Yeah, the GLib documentation is not very good at pointing this out, unfortunately. I'm also thinking about maybe creating a slightly incompatible version which might use "c_" as a prefix instead of "g_". There would also need to be some changes to the interface and not only the return values because the methods that do a realloc internally only return a pointer to the object itself (e.g. GString*) for chaining and therefore cannot be used to signal an error condition. But not sure, yet if this is a good idea or just creates confusion. For the moment I just want to provide the (in my opinion) by far most important classes of GLib because I always missed something like that in the C standard library. This is also why I chose to implement it header-only. It should be as easy as possbile for people to use them. The out of memory handling is very unfortunate and you should probably not use this code in the middle of a database transaction or something similar but I think for most user level code and situations where you would handle out of memory with exit anyway it is ok as it is.

aheck 4y ago

You're right, calling exit when out of memory is at least controversial if not even bad. I still do it because the goal is to be source compatible with GLib. And this is how GLib handles out of memory, unfortunately. https://libsoup.org/glib/glib-Memory-Allocation.html#g-malloc https://libsoup.org/glib/glib-Memory-Allocation.html#g-mallo... https://stackoverflow.com/questions/16974254/glib-handle-out-of-memory https://stackoverflow.com/questions/16974254/glib-handle-out... Thanks for pointing out the null termination issue. This was actually a bug and I just fixed it in g_string_append_len. The other _len methods look fine to me. Since CLib aims to be source compatible with GLib the documentation for the respective classes of GLib should do it: https://libsoup.org/glib/glib-Strings.html https://libsoup.org/glib/glib-Strings.html https://libsoup.org/glib/glib-Hash-Tables.html https://libsoup.org/glib/glib-Hash-Tables.html https://libsoup.org/glib/glib-Doubly-Linked-Lists.html https://libsoup.org/glib/glib-Doubly-Linked-Lists.html

andrewmcwatters 4y ago
I had no idea GLib did that. Their string implementation seems to be the best one to use, too, for those looking for a capacity, length, and data implementation. I'm a bit disappointed to know this now. But good on you for being strictly compatible; I feel like many people would fudge the implementation. Thanks for sharing this.
- aheck 4y ago
  Yeah, the GLib documentation is not very good at pointing this out, unfortunately. I'm also thinking about maybe creating a slightly incompatible version which might use "c_" as a prefix instead of "g_". There would also need to be some changes to the interface and not only the return values because the methods that do a realloc internally only return a pointer to the object itself (e.g. GString*) for chaining and therefore cannot be used to signal an error condition. But not sure, yet if this is a good idea or just creates confusion. For the moment I just want to provide the (in my opinion) by far most important classes of GLib because I always missed something like that in the C standard library. This is also why I chose to implement it header-only. It should be as easy as possbile for people to use them. The out of memory handling is very unfortunate and you should probably not use this code in the middle of a database transaction or something similar but I think for most user level code and situations where you would handle out of memory with exit anyway it is ok as it is.