@h2loop/safe-c-coding-plugin 0.3.0 → 0.3.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@h2loop/safe-c-coding-plugin",
-  "version": "0.3.0",
+  "version": "0.3.1",
   "description": "Safe-C coding plugin for Hydron — MISRA C:2012-aligned defensive C/C++ guidelines as an always-on skill plus a safe-c-reviewer subagent",
   "type": "module",
   "license": "UNLICENSED",

package/skills/safe-c-coding/SKILL.md

@@ -22,8 +22,8 @@ Short list, verified on every function you write or edit. Everything else lives
 3. **No dynamic memory, recursion, VLAs, `exit`/`abort`/`longjmp`, or unbounded string functions** — use the substitutes in guidelines.md.
 4. **No implicit narrowing and no signed/unsigned mixing** — every conversion explicit.
 5. **Braces on every body, a `default` on every `switch`, every return value used or `(void)`-discarded.**
-6. **Every identifier you reference is one you have actually read in a declaration.** Before writing a macro, struct or union member, type, enum constant, global, or function name that this file does not itself define, find its declaration in the headers and context you were given, and copy the spelling from there. Names that feel like they *must* exist — a size or count macro accompanying a table, a member named after the quantity it holds, an obvious-looking helper — very often do not, and a plausible invented name is a compile error, not a style blemish. Note in particular that a length may be exposed as a variable rather than a macro, and that a member's name usually describes its slot, not its physical meaning. If you cannot find a declaration for something you need, say so rather than guessing at it.
-7. **Every guard you add must be able to fail.** Before testing a value against zero, NULL, or a range limit, establish what the value actually is. If it is fixed at compile time — a macro expanding to a literal expression, an enum constant, a `sizeof`, a `const` object with a visible initialiser, the address of a declared object or array — then the test has one permanent answer, and an always-true or always-false controlling expression is a required-rule violation (dead code), not extra safety. Guard the things that genuinely vary at run time: parameters, values read from globals or hardware, results of computation. If the worry is that a *configured constant* could be set wrongly, check it at compile time with `#if` or a static-assertion idiom, which costs nothing at run time and cannot be dead code. This does **not** loosen items 1 and 2: an index or pointer that arrives as a parameter, or is read from a global, a struct, or a device, is precisely the varying kind, and still needs its real `if` guard. The two rules point the same way — put guards where a value can actually surprise you, and nowhere else.
+6. **Every identifier you reference is one you have actually read in a declaration.** A plausible invented name — a size/count macro that feels like it must accompany a table, a member named after the quantity it holds rather than its declared name — is a compile error, not a style blemish. Full rule: see guidelines.md § General.
+7. **Every guard you add must be able to fail.** A guard whose tested value is fixed at compile time (a macro, enum constant, `sizeof`, `const` with a visible initialiser, a declared object's address) has one permanent answer — that's an always-true/-false controlling expression, a dead-code violation, not extra safety; check it with `#if`/a static assertion instead. This does **not** loosen items 1 and 2: a value that arrives as a parameter or is read from a global, struct, or device is precisely the varying kind and still needs its real `if` guard. Full rule: see guidelines.md § Control flow.
 
 Where one of these clashes with the surrounding house style, follow the guideline in the code you write and note the divergence in one line.
 
@@ -72,7 +72,7 @@ Walk the lines you wrote — not the whole file — and answer each question exp
 6. **Every branch construct**: braced bodies, a `default` in every `switch`, a terminating `else` where the chain must be exhaustive.
 7. **Anything on the banned-facility list** (dynamic memory, recursion, VLAs, `exit`/`abort`/`longjmp`, unbounded string functions): replaced by its substitute, or deviated from with a written justification.
 
-State the result of the audit in one or two lines before you finish, so the check is visible rather than assumed.
+State the result of the audit before you finish: for every Critical or Standard finding raised — by the reviewer subagent or by your own re-read — name the finding and the specific edit that resolved it. "Audit passed" or "no issues found" with no re-read behind it is not an audit; a finding with no matching fix next to it is not an audit either.
 
 ## Preferred patterns