[Audit][High] worldToLocal uses @mod which may produce incorrect results for negative coordinates

[MichaelFisher1997]

🔍 Module Scanned

(automated audit scan)

📝 Summary

The function uses for coordinate wrapping, while the closely related function uses . This inconsistency suggests a potential bug where may produce incorrect (potentially out-of-bounds) local coordinates when given negative world coordinates, causing crashes or data corruption when accessing blocks at negative positions.

📍 Location

• File:
• Function/Scope:

🔴 Severity: High

• High: Memory corruption, crashes when accessing blocks at negative world coordinates (e.g., terrain near spawn, exploration in negative direction)

💥 Impact

When a player moves to negative X or Z coordinates (e.g., exploring west or north of spawn), block access through and will receive incorrect local coordinates. If returns a negative value that is then cast to , this causes an out-of-bounds access or crash. Minecraft-style voxel games commonly have players exploring negative coordinate space, making this a high-impact user-visible bug.

🔎 Evidence

The inconsistency between (which correctly handles negative division) and (which may not produce correct positive remainders for negative inputs) is the core issue.

Callers in and use this function to get local block coordinates from world positions. If :

• returns (correct)
• should return but may produce garbage due to behavior

🛠️ Proposed Fix

Use a consistent approach that guarantees positive remainders for negative inputs:

Or use the standard math pattern for guaranteed-positive modulo:

✅ Acceptance Criteria

• returns (verified by unit test)
• returns (verified by unit test)
• returns (verified by unit test)
• All existing tests in pass
• Blocks at negative world coordinates can be correctly accessed via

📚 References

• Zig 0.16 documentation: computes remainder with result sign matching divisor for positive divisors
• Zig 0.16 : integer division rounding toward negative infinity (correct for negative coordinates)
• Minecraft coordinate system: world extends infinitely in all directions from origin (0, 0)
• Related: at line 252 correctly uses for negative-aware division

[github-actions]

Bug Analysis:

The issue claims worldToLocal at modules/world-core/src/chunk.zig:259-264 uses @mod which may produce incorrect results for negative coordinates. However, based on Zig 0.16 semantics:

• @mod(a, b) returns remainder with sign matching the divisor
• With positive divisor CHUNK_SIZE_X = 16, @mod(-1, 16) = 15 (non-negative)
• @intCast(15) to u32 = 15 (correct)

Validation:

Input	@mod result	@intCast to u32	Expected
worldToLocal(-1, -1)	15	15	15 ✓
worldToLocal(-17, -17)	15	15	15 ✓
worldToLocal(-1000, -1000)	8	8	8 ✓

The existing tests at src/world_inline_tests.zig:107-116 explicitly test negative coordinates and expect 15 for -1 and -17 inputs.

Conclusion:

This appears to be a false positive. The @mod builtin with a positive divisor always returns a non-negative result in Zig 0.16, so the current implementation correctly handles negative coordinates. The tests should pass.

If there's a specific Zig version or configuration where @mod behaves differently, please provide reproduction steps and the exact Zig version. Otherwise, this audit finding can be dismissed as the implementation is semantically correct.

opencode session  |  github run