dohertj2/lmxopcua
1
0
Fork 0
Code Issues 1 Pull Requests 1 Actions Packages Projects Releases Wiki Activity

fix(driver-modbus-addressing): resolve Medium code-review finding (Driver.Modbus.Addressing-002)

Browse Source 
Reject an empty 3rd field in the address parser by checking parts[2].Length > 0
before the All(char.IsDigit) guard, so a trailing-colon typo like "40001:F:"
produces a diagnostic instead of silently parsing as a scalar.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Joseph Doherty
2026-05-22 09:52:52 -04:00
parent c5f2d91bcb
commit ba52c179fd
2 changed files with 61 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
code-reviews/Driver.Modbus.Addressing/findings.md
View File

@@ -7,7 +7,7 @@
| Review date | 2026-05-22 |
| Commit reviewed | `76d35d1` |
| Status | Reviewed |
| Open findings | 8 |
| Open findings | 3 |
## Checklist coverage
@@ -66,7 +66,7 @@ assertion was corrected from 16640 to 0x2100 with system-bank regression cases a
| Severity | Medium |
| Category | Correctness & logic bugs |
| Location | `ModbusAddressParser.cs:86-94` |
| Status | Open |
| Status | Resolved |
**Description:** In the 3-field disambiguation, an empty 3rd field (`40001:F:`) reaches
`parts[2].All(char.IsDigit)`. `Enumerable.All` returns true for an empty sequence, so the empty
@@ -79,7 +79,7 @@ colon gets no diagnostic.
**Recommendation:** Reject an empty 3rd field explicitly, or guard the `All(char.IsDigit)` branch
with `parts[2].Length > 0`.
**Resolution:** _(open)_
**Resolution:** Resolved 2026-05-22 — added an explicit `parts[2].Length == 0` check before the `All(char.IsDigit)` branch that returns a descriptive error, so a trailing colon typo produces a diagnostic instead of silently parsing as a scalar.
### Driver.Modbus.Addressing-003
@@ -88,7 +88,7 @@ with `parts[2].Length > 0`.
| Severity | Medium |
| Category | Correctness & logic bugs |
| Location | `ModbusAddressParser.cs:405-406`, `ModbusAddressParser.cs:128` |
| Status | Open |
| Status | Resolved |
**Description:** `LooksLikeByteOrderToken` classifies any 4-letter token as a byte-order token.
A 3-field address whose 3rd field is a 4-letter type-like token (e.g. `40001:S:BOOL`) is routed
@@ -101,7 +101,7 @@ byte order, so the diagnostic actively misdirects.
the error message to mention that field 3 is a byte order and field 2 is the type, or attempt a
type-parse fallback before emitting the byte-order error.
**Resolution:** _(open)_
**Resolution:** Resolved 2026-05-22 — in the 3-field disambiguation error path, a 4-letter alphanumeric token that looks like a type code now produces a diagnostic explicitly stating that field 3 is the byte-order slot and field 2 is the type slot, directing the user to the correct fix.
### Driver.Modbus.Addressing-004
@@ -110,7 +110,7 @@ type-parse fallback before emitting the byte-order error.
| Severity | Medium |
| Category | Correctness & logic bugs |
| Location | `ModbusAddressParser.cs:182-194` |
| Status | Open |
| Status | Resolved |
**Description:** The bit suffix is stripped using `text.IndexOf('.')` — the first dot. An input
such as `40001.5.3` produces a bit text of "5.3", rejected by `byte.TryParse` with the generic
@@ -124,7 +124,7 @@ asserting it, and the diagnostics for these malformed inputs are inconsistent.
region/offset segment is non-empty and dot-free after the strip so malformed inputs get a precise
diagnostic.
**Resolution:** _(open)_
**Resolution:** Resolved 2026-05-22 — switched to `LastIndexOf('.')`, added a non-empty guard for the address segment before the dot, and added a check that the address segment itself contains no dot (diagnosing multi-dot inputs with "contains multiple dots" rather than a confusing bit-index error).
### Driver.Modbus.Addressing-005
@@ -133,7 +133,7 @@ diagnostic.
| Severity | Medium |
| Category | Error handling & resilience |
| Location | `ModbusAddressParser.cs:200-213` |
| Status | Open |
| Status | Resolved |
**Description:** `TryParseRegionAndOffset` tries family-native, then mnemonic, then Modicon. When
all three fail it returns false with whatever error the Modicon parser last wrote (comment: "the
@@ -148,7 +148,7 @@ Modicon "must be 5 or 6 digits" error, hiding the real cause (e.g. "contains non
prefix, prefer and preserve the family-native error rather than letting the Modicon fallback
overwrite it.
**Resolution:** _(open)_
**Resolution:** Resolved 2026-05-22 — the family-native error is now captured in `familyNativeError` and, after all three branches fail, preferred over the Modicon fallback error when it is non-null (indicating the address matched a family prefix but failed deep inside the helper).
### Driver.Modbus.Addressing-006
@@ -202,7 +202,7 @@ structured tag form and is intentionally out of grammar scope.
| Severity | Medium |
| Category | Testing coverage |
| Location | `tests/Drivers/ZB.MOM.WW.OtOpcUa.Driver.Modbus.Addressing.Tests/` |
| Status | Open |
| Status | Resolved |
**Description:** Several edge cases of the address arithmetic are untested or asserted wrong:
(a) DL205 system V-memory mapping is tested only with the incorrect expected value
@@ -217,7 +217,7 @@ are exactly the high-risk surface this module owns, and they are the least cover
and for the parser count/bit/field edge cases. Correct the V40400 assertion as part of fixing
finding -001.
**Resolution:** _(open)_
**Resolution:** Resolved 2026-05-22 — added `ModbusAddressEdgeCaseTests.cs` covering: empty 3rd-field rejection, multi-dot input rejection, `UserVMemoryToPdu` overflow, `AddOctalOffset` overflow via Y and C helpers, `SystemVMemoryToPdu` base/overflow, `MelsecAddress.ParseHex` overflow, `DRegisterToHolding` and `MRelayToCoil` bank-base overflow.
### Driver.Modbus.Addressing-009