design flaw: undefined zig pointers: are they non-null or not?

[andrewrk]

This issue is not related to allowzero.

A Zig pointer, such as *i32 or [*]u8, is guaranteed to be non-null. Optional pointers must be used to gain null as a possible value: ?*i32 or ?[*]u8. So we put the nonnull LLVM attribute on functions. However, that makes this simple Zig code undefined behavior, even in debug mode:

pub fn main() void {
    var not_even_used: *i32 = undefined;
    foo(not_even_used);
}

fn foo(not_even_used: *i32) void {}

Because not_even_used is undefined, that means it could be 0 which violates the nonnull attribute. This could be solved by not putting nonnull attribute on pointer parameters, though it would be unfortunate since most of the time nonnull is correct.

It's also a question of whether to put nonnull on loads, stores, and other places having to do with Zig pointers.

The more I think about it, the more I think the answer is that Zig pointers have a slightly different property than nonnull. The property is nonnull_or_undefined. This is not an LLVM concept that currently exists, but I have a gut instinct that it should. Any time that the nonnull attribute would allow the optimizer to do anything useful, if the value were nonnull_or_undefined it should allow the optimizer to do the same thing. The only issue is that undefined is violating nonnull.

Related:

• Zig's proposed definition of undefined (audit analysis of undefined values; make it clear when undefined is allowed or not #1947)
• Illegal Behavior (terminology update: use the phrase "detectable illegal behavior" rather than "safety-checked undefined behavior" #2402)
• empty slice ptr cast with offset of 0 fails (empty slice ptr cast with offset of 0 fails #2140)

I promise that the above Zig code snippet will not make it into the 1.0 language specification (#75) as undefined behavior. This will be resolved some way or another.

[jlombera]

Slices are also affected by this. Following code causes segmentation fault at runtime instead of an out-of-bounds panic in debug mode:

fn foo(slice: []u8) void {
    const x = slice[0];
    _ = x;
}

pub fn main() void {
    var slice: []u8 = undefined;
    foo(slice);
}

I guess, in general, undefined is not safe around anything involving pointers at the moment.

[atmnk]

Not sure if this could be related but following code leads to seg fault with undefined pointer. Just exploring zig.

const Complex = struct {
    real: f32,
    imaginary: f32,
    fn add(self:Complex,other:Complex) Complex{
        return Complex{
            .real = self.real+other.real,
            .imaginary = self.imaginary+other.imaginary
        };
    }
};
test "simple test" {
    var a:*Complex=undefined;
    a.real = 1.0;
    const b =Complex{
        .real = 1.0,
        .imaginary = 1.0,
    };
    const c= b.add(a.*);
    try std.testing.expect(c.real==1.0);
    try std.testing.expect(c.imaginary==1.0);
}

The output
1/1 main.test.simple test... Segmentation fault at address 0xaaaaaaaaaaaaaaaa Panicked during a panic. Aborting. error: the following test command crashed: /Users/atmaramnaik/work/practice/zig/day3/zig-cache/o/718a27f2b8f12de912fa6156d0c7f660/test

[nektro]

yes that segfault is expected given your code

[nektro]

is there a use case where having an undefined pointer ever makes sense? could assigning undefined to a pointer be make a compile error? (sure there would be ways to trick it but it would make that it is illegal behavior a lot more obvious)

[InKryption]

Generally speaking I think the way a pointer becomes undefined is most frequently as a field of a struct in an allocated slice, ie try allocator.alloc(struct { foo: []u8 }, n) - so, @memset & aliasing via @ptrCast. There could also possibly some generic code that initializes a value of a specified type T to undefined, which is initialized by a callback with some parameters.
I think it would be more useful to make it runtime illegal behaviour to dereference an undefined pointer, via usage of special values in safe modes (ie ptr=0). There's a proposal for that, however I can't find it at the moment.