[siracozmen01]

Problem

The rule from #119 says a value struct a call takes back carries no raw pointer and size into the library's data. maul-ui's audit found muiAccessUpdate. The library fills it from muiContext_GetAccessUpdate, but the header also documents it as input a host builds. To muiAccessTree_Apply its pointers are the caller's to keep valid, as with any buffer argument, so read literally the rule would call a documented caller-built input a breach.

Change

maul/files/docs/internals/maul-conventions.md: one sentence after the fill-only exception. A struct the header also documents as caller-built input may point into the library's data, provided the call that takes it reads through it as through any buffer argument: only within the ranges its own pointers and counts state, checking every count, offset and index it reads there as untrusted, and relying on nothing the library validated earlier. A header line alone exempts nothing: a zone call that follows indexes the open validated stays under the rule.

Verification

This is documentation only. maul-ui (#338, #339), maul-tween (#297) and maul-nav (#330, #331) close their issues under this rule only after confirming their calls read that way; any place that trusts an index found inside the data is a bug to fix.

[siracozmen01]

Review at 6a06af1: changes needed (1). The new sentence opens the loophole you asked about.

1. The exemption depends on what the header says, not on what the call does. "So may one the header also documents as input a caller builds" lets any struct escape the rule through one header sentence. The weak point is "checks every count, offset and index it can": a call that cannot check something can say so and still qualify.

• Concrete case: maul-locale adds "a caller may also build a mlocTimeZone" to zone.h. The zone calls keep trusting the zone and primary indexes inside zones, because those bytes were validated when the data was opened, and the new sentence would cover them. That is exactly #334's bug. The same goes for muiDrawList or mnavPath if their headers gain such a line.
• What separates muiAccessUpdate from mlocTimeZone is how the call reads through the struct, not who built it:
  • muiAccessTree_Apply treats the update's arrays like any buffer argument: it reads only inside the ranges the struct's own pointers and counts state, and checks every value it reads from them as untrusted.
  • A zone call follows indexes it finds inside the bytes beyond any extent the struct states, trusting an earlier validation. That is the case the rule has to forbid.
• Please tie the exemption to that behavior. For example: "So may one the header also documents as input a caller builds, such as an accessibility update, provided the call that takes it reads through it as through any buffer argument: only within the ranges its own pointers and counts state, checking every count, offset and index it reads there as untrusted, and relying on nothing the library validated earlier. Its pointers and counts are then the caller's to keep valid."
• With that wording, a header sentence alone exempts nothing. muiDrawList and mnavPath stay fill-only, and mlocTimeZone stays under the rule even if its header calls it caller-built. maul-ui's check for #339 becomes concrete: Apply must never read outside the update's stated ranges and must never trust their contents.

Read, not run.

[siracozmen01]

Re-review at 2107c76: ready. My finding is resolved in the rule.

• The exception now holds only "provided the call that takes it reads through it as through any buffer argument: only within the ranges its own pointers and counts state, checking every count, offset and index it reads there as untrusted, and relying on nothing the library validated earlier". A header sentence alone no longer exempts a struct. mlocTimeZone's calls still rely on the zones unit having been validated at open, so it stays under the rule, and a struct the library alone fills (muiDrawList, mnavPath) qualifies only if the call that takes it back really reads it this way.
• "Its pointers and counts are then the caller's to keep valid" puts memory validity where it is for any buffer argument.

Recommended, not blocking: the body still describes the earlier wording. Its Change says the call "still checks every count, offset and index it can without trusting the pointers", and its Verification says the same in short. The body becomes the squash commit message, so it would record the weaker rule. Please bring the Change line in line with the file's "provided ..." clause.

Read, not run.