# Why casting an empty slice to a pointer isn't checked?

**URL:** <https://ziggit.dev/t/why-casting-an-empty-slice-to-a-pointer-isnt-checked/6986>\
**Category:** Help\
**Tags:** safety\
**Created:** [November 23, 2024, 9:15pm UTC](https://ziggit.dev/t/why-casting-an-empty-slice-to-a-pointer-isnt-checked/6986 "2024-11-23T21:15:20Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![tekhnus](https://ziggit.dev/user_avatar/ziggit.dev/tekhnus/32/3826_2.png) [@tekhnus](https://ziggit.dev/u/tekhnus)\
**Post date:** [November 23, 2024, 9:15pm UTC](https://ziggit.dev/t/why-casting-an-empty-slice-to-a-pointer-isnt-checked/6986/1 "2024-11-23T21:15:20Z")

</div>

Hi everyone!

I noticed that casting an empty slice to a pointer doesn’t produce an error by itself.  
For example, the following code:

```zig
const std = @import("std");

pub fn getSlice() []i32 {
    return &.{};
}

pub fn main() void {
    const foo: []i32 = getSlice();
    const val: *i32 = @ptrCast(foo);
    std.debug.print("Hello, {d}!\n", .{val.*});
}

```

crashes on `print` with `General protection exception`. I wonder why it’s not `@ptrCast` that fails?

---

<div class="post-metadata">

**Author:** ![dimdin](https://ziggit.dev/user_avatar/ziggit.dev/dimdin/32/1457_2.png) [@dimdin](https://ziggit.dev/u/dimdin)\
**Post date:** [November 23, 2024, 9:30pm UTC](https://ziggit.dev/t/why-casting-an-empty-slice-to-a-pointer-isnt-checked/6986/2 "2024-11-23T21:30:37Z")

</div>

Hi @tekhnus

It crashes when you dereference the pointer (`val.*`).

The problem is that you are casting to get the pointer.  
If you use `foo.ptr` you get:

```zig
error: expected type '*i32', found '[*]i32'
    const val: *i32 = foo.ptr;
                      ~~~^~~~
note: a many pointer cannot cast into a single pointer

```

Zig compiler complains because `[*]i32` can have zero elements.  
Zig compiler cannot complain when calling [`@ptrCast`](https://ziglang.org/documentation/master/#ptrCast) because this is a no-operation to signal the compiler that you know what you are doing (e.g. you just checked that `foo.len > 0`).

Welcome to ziggit 🙂

---

<div class="post-metadata">

**Author:** ![tekhnus](https://ziggit.dev/user_avatar/ziggit.dev/tekhnus/32/3826_2.png) [@tekhnus](https://ziggit.dev/u/tekhnus)\
**Post date:** [November 23, 2024, 9:42pm UTC](https://ziggit.dev/t/why-casting-an-empty-slice-to-a-pointer-isnt-checked/6986/3 "2024-11-23T21:42:55Z")

</div>

> Zig compiler cannot complain when calling [`@ptrCast`](https://ziglang.org/documentation/master/#ptrCast)

I understand that. The question is, why don’t we get a _runtime_ safety check in debug build mode? I suppose that performing such cast is undefined behavior (analogous to casting a null pointer to \*i32 which is undefined behaviour and causes `cast causes pointer to be null` at runtime)?

---

<div class="post-metadata">

**Author:** ![dimdin](https://ziggit.dev/user_avatar/ziggit.dev/dimdin/32/1457_2.png) [@dimdin](https://ziggit.dev/u/dimdin)\
**Post date:** [November 23, 2024, 9:52pm UTC](https://ziggit.dev/t/why-casting-an-empty-slice-to-a-pointer-isnt-checked/6986/4 "2024-11-23T21:52:13Z")

</div>

I agree that casting a zero-item slice to a single-item pointer can be [zig undefined behavior](https://ziglang.org/documentation/master/#Undefined-Behavior).

---

<div class="post-metadata">

**Author:** ![jumpnbrownweasel](https://ziggit.dev/user_avatar/ziggit.dev/jumpnbrownweasel/32/263_2.png) [@jumpnbrownweasel](https://ziggit.dev/u/jumpnbrownweasel)\
**Post date:** [August 31, 2026, 4:07pm UTC](https://ziggit.dev/t/why-casting-an-empty-slice-to-a-pointer-isnt-checked/6986/5 "2026-08-31T16:07:48Z")

</div>

> [@dimdin](#):
>
> [zig undefined behavior](https://ziglang.org/documentation/master/#Undefined-Behavior)

For future readers, here’s the updated link (Undefined was changed to Illegal)

> **[Illegal Behavior - Documentation - The Zig Programming Language](https://ziglang.org/documentation/master/#Illegal-Behavior)**
>
> Zig is a general-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
