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
# 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`
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Validate
SG_signal definitions and report malformed or unsupported syntaxDescription
Following strict validation of
BO_frame definitions, add equivalent validation forSG_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.0junkor1junk, are partially parsed and accepted.SG_ Value m1 : ...is treated as an ordinary signal namedValue m1, without multiplexing conditions.SG_is silently skipped.Scope
@0or@1and signedness+or-.1..64bits.minimum <= maximum.M,mN, and their combinations until multiplexing is implemented.path:line: description.Acceptance criteria
Out of scope
Duplicate detection, multiplexing support, and
VAL_support remain separate tasks.Suggested branch
codex/validate-sg-definitions