Add support for BYTE, WORD and DWORD variables

[sclaiborne]

Depends on StringExt 1.1.0 (StringExt#12, merged and published as v1.1.0).

Problem

BYTE/WORD/DWORD were identified correctly — PV_ninfo returns 17/18/19 and the CSV_TYPE_enum values match — and then rejected as unsupported in both csvOpenVar and csvSaveVar. A DWORD line left the target variable silently untouched, incremented FailedLineCount, and surfaced only as a generic CSV_ERR_LINEFAILURE, with the actual reason buried in the .csvlog.

Writing — hex by default, configurable

New IN.CFG.BitStringFormat:

Value	Output
CSV_BITFORMAT_HEX_0X (0, default)	0x00FF
CSV_BITFORMAT_HEX_IEC	16#00FF
CSV_BITFORMAT_DECIMAL	255

Default 0 means hex without anyone configuring anything, and no CSVFn_Init change is needed. Decimal exists for exchanging files with systems that don't accept hex — the same reason VarTools formats these types as decimal, which stays as it is.

In hex modes, values are zero-padded to the width of the source type (2/4/8 digits), so a column lines up and the width of the underlying variable is visible in the file. Decimal output is not padded (a BYTE of 5 writes 0x05 in hex, 5 in decimal).

Reading — permissive, regardless of the setting

A prefixed literal (0xFF, 16#FF, $FF) is hex; bare digits are decimal. Requiring the prefix for hex is what makes this unambiguous — otherwise 10 could reasonably mean either ten or sixteen. This means files written in either mode read back, and hand-written files behave the way someone would expect.

Two details:

• Decimal is accumulated by hand rather than with atoui(), which saturates on overflow instead of reporting it — so 99999999999 is rejected rather than quietly becoming 4294967295.
• Every value is range-checked against the width of the target, so 0x1FF into a BYTE is an error rather than a truncation.

LWORD is deliberately still unsupported — it needs 64-bit parsing and a ULINT store, which CSVFileLib doesn't have either. That should stand on its own.

Compatibility

No file CSVFileLib ever produced contains a bit-string value (they were rejected, and on save the original line was written back verbatim), so there is no legacy format to preserve. Existing files and every other type are unaffected.

Reviewer note

The new cases sit immediately before the "Unsupported and Invalid types" banner in both csvOpenVar and csvSaveVar. Placement matters here: inside that group, STRUCT/ULINT/DATE/ARRAY_OF_STRUCT would fall through into the bit-string handler and write to a struct's address as if it were a DWORD. Worth confirming the fallthrough group is intact when reading the diff.

Verification

• CI green — builds Intel and ARM against the published StringExt 1.1.0.
• Locally compiled and linked clean for Intel; no new warnings. (The three csvOpenVar.c -Woverflow/-Wmaybe-uninitialized warnings in the log are pre-existing, in the LREAL path.)
• Not exercised on a target: this machine's AR install has no firmware module for the example's CPU, so no RUC package is produced locally.

The second commit refreshes the vendored example/.../Loupe/stringext to 1.1.0 along with package.json and package-lock.json — necessary because build.yml has no lpm install step and builds the committed copy. Existing file names were kept so it reads as a content change rather than case-only renames.

🤖 Generated with Claude Code