# Validate `SG_` signal definitions and report malformed or unsupported syntax ## Description Following strict validation of `BO_` frame definitions, add equivalent validation for `SG_` signal definitions. Currently, some malformed statements are accepted silently, and unsupported syntax can produce incorrect decoding. Examples of current behavior: - `@2+` is interpreted as Motorola instead of being rejected. - Numeric fields containing suffixes, such as `0junk` or `1junk`, are partially parsed and accepted. - `SG_ Value m1 : ...` is treated as an ordinary signal named `Value m1`, without multiplexing conditions. - A statement containing a tab after `SG_` is silently skipped. ## Scope - Validate statement structure and require a nonempty signal name without whitespace. - Accept spaces and tabs between syntax elements. - Parse numeric fields completely, rejecting overflow and trailing characters; preserve support for fractional values and scientific notation in physical parameters. - Accept only byte order `@0` or `@1` and signedness `+` or `-`. - Require signal lengths within `1..64` bits. - Validate that the signal fits within the frame's declared payload length, using the appropriate Intel or Motorola bit traversal. - Reject NaN and infinite values for factor, offset, minimum, and maximum; require `minimum <= maximum`. - Explicitly reject multiplexing markers `M`, `mN`, and their combinations until multiplexing is implemented. - Preserve the error format `path:line: description`. ## Acceptance criteria - [ ] Existing valid signal definitions continue to parse successfully. - [ ] Malformed and unsupported definitions stop parsing with a clear error. - [ ] Regression tests cover the cases above, numeric boundaries, and Intel/Motorola payload boundaries. - [ ] Existing parser and decoder tests pass. - [ ] README documents the new validation rules and limitations. ## Out of scope Duplicate detection, multiplexing support, and `VAL_` support remain separate tasks. ## Suggested branch `codex/validate-sg-definitions`