mach icon indicating copy to clipboard operation
mach copied to clipboard

Object System: Object ID space is more limited than it should be, causing int truncation panics

Open msg-programs opened this issue 3 months ago • 0 comments

Extracted from a series of on the Mach discord starting with this one. Seems important enough to document in an issue here too.

TL;DR: One should be able to have up to 64 object types per module, but the actual number is much smaller and depends on the names of the object types.


According to a comment in the module code, the object system should handle up to 64 object types per module.

https://github.com/hexops/mach/blob/8ef4227770880f69300e475c7c65f0ba1f2604a5/src/module.zig#L21-L26

In practice, this isn't the case, as the object_name_id is set to the ID of the name in a string table.

https://github.com/hexops/mach/blob/8ef4227770880f69300e475c7c65f0ba1f2604a5/src/module.zig#L654-L660

The string table ID is the offset of the name in the string table's byte storage, which causes the object name IDs to grow faster than one would expect:

Object names + their IDs:
name: windows, id: 0
name: shaders, id: 8
name: vertex_data, id: 16
name: scenes, id: 28

StringTable's byte storage:
0               1               2
0123456789abcdef0123456789abcdef012
windows0shaders0vertex_data0scenes0
^0      ^8      ^16         ^28

This causes a panic after more than 64 bytes are written to the string table, as the ID can't be casted to an u6 without trucating. Object names with e.g. 85 bytes were also noted to cause issues on the discord conversation.

A comment from the BDFL on this issue can be found here.

msg-programs avatar Oct 12 '25 12:10 msg-programs