The Skill can guide agents to generate unsafe memory access that bypasses Go's type system
Source references: 6The reference explicitly teaches `unsafe.Pointer` and gives examples of type reinterpretation, address arithmetic, and syscall arguments. Such code bypasses the type system, and the examples cannot ensure that an agent's application has valid input lengths, alignment, object lifetimes, or target-platform layout.
If an agent applies these patterns to data or layouts that do not satisfy their prerequisites, the resulting program may crash, read incorrect data, or corrupt memory. With externally supplied input, this can become a denial-of-service or data-integrity risk.
The reference does contain unsafe.Pointer examples, but low-level pointer handling is an expressly stated topic, not an instruction to execute such code unconditionally. The surrounding text limits use to Go-spec patterns, labels other patterns undefined, and recommends modern APIs that avoid uintptr arithmetic; the shown arithmetic is explicitly constrained to one expression. These lines show no concrete bad bounds, alignment, or lifetime handling, so they do not support the claimed unsafe implementation risk beyond the inherent nature of the topic. Users can still prohibit unsafe unless a reviewed FFI or layout need exists.
This assessment concerns the code and conditions shown, not proof that harm has occurred.## `unsafe.Pointer``unsafe.Pointer` bypasses Go's type system for FFI and low-level memory manipulation. Only the 6 patterns from the Go spec are safe; any other pattern is undefined behavior.### The 6 Valid Patterns (from the Go spec)These are the ONLY safe ways to use `unsafe.Pointer`. Any other pattern is undefined behavior.Show 5 other places
**Pattern 1: Convert `*T` to `*U` via `unsafe.Pointer`**```go// Reinterpret a float64 as its raw bitsf := 1.5bits := *(*uint64)(unsafe.Pointer(&f))```**Pattern 2: Convert `unsafe.Pointer` to `uintptr` and back (same expression)**```go// Pointer arithmetic — MUST be a single expressionp := unsafe.Pointer(uintptr(unsafe.Pointer(&s.field)) + offset)```**Pattern 4: `syscall.Syscall` arguments**```gosyscall.Syscall(SYS_READ, fd, uintptr(unsafe.Pointer(&buf[0])), uintptr(len(buf)))```### The 6 Valid Patterns (from the Go spec)These are the ONLY safe ways to use `unsafe.Pointer`. Any other pattern is undefined behavior.### Modern Alternatives (prefer these)| Function | Since | Purpose || --- | --- | --- || `unsafe.Add(ptr, len)` | Go 1.17 | Pointer arithmetic without `uintptr` conversion || `unsafe.Slice(ptr, len)` | Go 1.17 | Create slice from pointer + length || `unsafe.String(ptr, len)` | Go 1.20 | Create string from pointer + length || `unsafe.SliceData(s)` | Go 1.17 | Get pointer to slice's backing array || `unsafe.StringData(s)` | Go 1.20 | Get pointer to string's backing array |These are safer than manual `uintptr` arithmetic because they keep values as pointers (visible to GC) throughout.