ziglang/zig

Fork 771

Code Issues 706 Pull requests 292 Activity Actions 25

Tuple literals allow for unsafe pointer casting #32165

New issue

Open

opened 2026年05月01日 21:00:36 +02:00 by danilrybakov · 2 comments

danilrybakov commented

2026年05月01日 21:00:36 +02:00

Copy link

Zig Version

0.17.0-dev.215+8c5542bd3

Steps to Reproduce and Observed Behavior

Steps to reproduce

zig run this code:

pubfnmain()void{// unsafe cast// from *const @Tuple(&.{*const [5:0]u8})// to *const @Tuple(&.{[]const u8})constfoo:*const@Tuple(&.{[]constu8})=&.{"hello"};_=foo;}

Observed behavior

Code compiles successfully

Expected Behavior

Zig refuses to compile code on the grounds of unsafe pointer casting.

### Zig Version 0.17.0-dev.215+8c5542bd3 ### Steps to Reproduce and Observed Behavior #### Steps to reproduce `zig run` this code: ```zig pub fn main() void { // unsafe cast // from *const @Tuple(&.{*const [5:0]u8}) // to *const @Tuple(&.{[]const u8}) const foo: *const @Tuple(&.{[]const u8}) = &.{"hello"}; _ = foo; } ``` #### Observed behavior Code compiles successfully ### Expected Behavior Zig refuses to compile code on the grounds of unsafe pointer casting.

danilrybakov added the

bug

label

2026年05月01日 21:00:36 +02:00

danilrybakov commented

2026年05月01日 21:01:22 +02:00

Author

Copy link

Additional information

When not casting a literal directly, zig correctly refuses to compile.
i.e., this code produces a compile error:

pubfnmain()void{constbar=&.{"hello"};constfoo:*const@Tuple(&.{[]constu8})=bar;_=foo;}

This behavior can lead to runtime segfaults. Example:
zig run -OReleaseFast this code:

conststd=@import("std");pubfnmain()void{varbar:*const[5:0]u8="hello";_=&bar;constfoo:*const@Tuple(&.{[]constu8,[]constu8})=&.{bar,bar};std.debug.print("{}\n",.{foo.*});}

### Additional information When not casting a literal directly, zig correctly refuses to compile. i.e., this code produces a compile error: ```zig pub fn main() void { const bar = &.{"hello"}; const foo: *const @Tuple(&.{[]const u8}) = bar; _ = foo; } ``` This behavior can lead to runtime segfaults. Example: `zig run -OReleaseFast` this code: ```zig const std = @import("std"); pub fn main() void { var bar: *const [5:0]u8 = "hello"; _ = &bar; const foo: *const @Tuple(&.{ []const u8, []const u8 }) = &.{ bar, bar }; std.debug.print("{}\n", .{foo.*}); } ```

danilrybakov commented

2026年05月01日 23:30:19 +02:00

Author

Copy link

Update

Now I'm more confused, because if I zig run -OReleaseFast these three pieces of code:

conststd=@import("std");pubfnmain()void{vara:*const[5:0]u8="hello";_=&a;constb=&.{a,a};std.debug.print("{}\n",.{b});}

conststd=@import("std");pubfnmain()void{vara:*const[5:0]u8="hello";_=&a;constb:*const@Tuple(&.{*const[5:0]u8,*const[5:0]u8})=&.{a,a};std.debug.print("{}\n",.{b});}

conststd=@import("std");pubfnmain()void{vara:*const[5:0]u8="hello";_=&a;constb:*conststruct{*const[5:0]u8,*const[5:0]u8}=&.{a,a};std.debug.print("{any}\n",.{b});}

The first one compiles and runs without errors, but the second and third compile and segfault at runtime, even though they only differ by an added type annotation that seemingly shouldn't even result in a cast.

So I still think that the issue I originally described is real, but the segfault may be a separate thing.

### Update Now I'm more confused, because if I `zig run -OReleaseFast` these three pieces of code: ```zig const std = @import("std"); pub fn main() void { var a: *const [5:0]u8 = "hello"; _ = &a; const b = &.{ a, a }; std.debug.print("{}\n", .{b}); } ``` ```zig const std = @import("std"); pub fn main() void { var a: *const [5:0]u8 = "hello"; _ = &a; const b: *const @Tuple(&.{ *const [5:0]u8, *const [5:0]u8 }) = &.{ a, a }; std.debug.print("{}\n", .{b}); } ``` ```zig const std = @import("std"); pub fn main() void { var a: *const [5:0]u8 = "hello"; _ = &a; const b: *const struct { *const [5:0]u8, *const [5:0]u8 } = &.{ a, a }; std.debug.print("{any}\n", .{b}); } ``` The first one compiles and runs without errors, but the second and third compile and segfault at runtime, even though they only differ by an added type annotation that seemingly shouldn't even result in a cast. So I still think that the issue I originally described is real, but the segfault may be a separate thing.

No Branch/Tag specified

Branches Tags

master

elfv2

spork8

restricted

0.16.x

panic-rewrite

parking-futex-lockfree

windows-Io-cleanup

Io-watch

ParseCommandLineOptions

windows-async-files

poll-ring

debug-file-leaks-differently

debug-file-leaks

ProcessPrng

elfv2-dyn

jobserver

threadtheft

io-threaded-no-queue

0.15.x

Io.net

comptime-allocator

restricted-function-pointers

cli

wasm-linker-writer

wrangle-writer-buffering

sha1-stream

async-await-demo

fixes

0.14.x

ast-node-methods

macos-debug-info

make-vs-configure

fuzz-macos

sans-aro

ArrayList-reserve

incr-bug

llvm-ir-nosanitize-metadata

ci-tarballs

ci-scripts

threadpool

0.12.x

new-pkg-hash

json-diagnostics

more-doctests

rework-comptime-mutation

0.11.x

ci-perf-comment

stage2-async

0.10.x

autofix

0.9.x

aro

hcs

0.8.x

0.7.x

Labels

Clear labels

This proposal is planned.

The web application for interactive documentation and generation of its assets.

backend/c

The C backend outputs C source code.

backend/llvm

The LLVM backend outputs an LLVM bitcode module.

backend/self-hosted

The self-hosted backends produce machine code directly.

binutils

Zig's included binary utilities: zig ar, zig dlltool, zig lib, zig ranlib, zig objcopy, and zig rc.

breaking

Implementing this issue could cause existing code to no longer compile or have different behavior.

build system

The Zig build system - zig build, std.Build, the build runner, and package management.

debug info

docs

An issue with documentation, e.g. the language reference or standard library doc comments.

error message

This issue points out an error message that is unhelpful and should be improved.

frontend

Tokenization, parsing, AstGen, ZonGen, Sema, Legalize, and Liveness.

fuzzing

incremental

Reuse of internal compiler state for faster compilation.

lib/c

This issue relates to Zig's libc implementation and/or vendored libcs.

lib/compiler-rt

This issue relates to Zig's compiler-rt library.

lib/cxx

This issue relates to Zig's vendored libc++ and/or libc++abi.

lib/std

This issue relates to Zig's standard library.

lib/tsan

This issue relates to Zig's vendored libtsan.

lib/ubsan-rt

This issue relates to Zig's ubsan-rt library.

lib/unwind

This issue relates to Zig's vendored libunwind.

linking

Zig's integrated object file and incremental linker.

miscompilation

The compiler reports success but produces semantically incorrect code.

This issue suggests language modifications. If it also has the "accepted" label then it is planned.

release notes

This issue or pull request should be mentioned in the release notes.

testing

This issue is related to testing the compiler, standard library, or other parts of Zig.

zig cc

Zig as a drop-in C-family compiler.

zig fmt

The Zig source code formatter.

zig reduce

The Zig source code reduction tool.

bounty

https://ziglang.org/news/announcing-donor-bounties

bug

Observed behavior contradicts documented or intended behavior.

contributor-friendly

This issue is limited in scope and/or knowledge of project internals.

downstream

An issue with a third-party project that uses this project.

enhancement

Solving this issue will likely involve adding new logic or components to the codebase.

infra

optimization

A task to improve performance and/or resource usage.

question

No questions on the issue tracker; use a community space instead.

regression

Something that used to work in a previous version stopped working

upstream

An issue with a third-party project that this project uses.

use case

Describes a real use case that is difficult or impossible, but does not propose a solution.

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

ziglang/zig#32165

No description provided.

Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?