>>107144019
>All the libraries that are nostd
by making this distinction you are proving my point
>Even in Zig you can't be sure if a call will allocate a memory or not.
and you can't be sure a rust function won't use-after-free if the programmer decided to go out of his way to prove a point, but most people are going to adhere to the behavior that the language enables and encourages, that's why they chose it
>When you call std.ArrayList.push, you have no idea if it will allocate new memory or not.
std.ArrayList is unmanaged as of zig 0.15.2, but I assume you mean the managed version and the append function. you are passing an allocator:
pub fn append(self: *Self, item: T) Allocator.Error!void {
const new_item_ptr = try self.addOne();
new_item_ptr.* = item;
}
self there is the struct that includes an allocator. and notice that whenever you call the function, you have to either handle or propagate the Allocator.Error, which is a pretty good hint even if you missed the fact that you are passing an allocator. for reference, this is how you usually use arraylist:
fn f(allocator: std.mem.Allocator) !void {
var al: std.ArrayList(i32) = .{};
defer al.deinit(allocator);
try al.append(allocator, 1);
try al.append(allocator, 3);
}
if you used the managed (deprecated) version you wouldn't need to pass it the allocator as an additional parameter, it would go in the first parameter (the "self" pointer), but it is still pretty obvious that there is an allocation happening
>you have to trace the syscalls or manually inspect the code
not really. usually you use something like this:
var gpa = std.heap.GeneralPurposeAllocator(.{
.stack_trace_frames = 20,
}){};
defer std.debug.assert(gpa.deinit() != .leak);
which will fail and give you a stack trace if you try to leak memory on a debug build
