feat(parser): implement pstring multi-byte length prefix variants (/B, /H, /h, /L, /l, /J)

[unclesp1d3r]

Summary

• Implement full GNU libmagic pstring length-prefix support with correct endianness: /H (2-byte BE), /h (2-byte LE), /L (4-byte BE), /l (4-byte LE), /B (1-byte, default)
• Add /J flag support (JPEG-style self-inclusive length) with combinable syntax (/HJ, /lJ, etc.)
• Replace unwrap() in library code with proper error propagation

Changes

• PStringLengthWidth enum expanded to 5 variants: OneByte, TwoByteBE, TwoByteLE, FourByteBE, FourByteLE
• Added length_includes_itself: bool field to TypeKind::PString for /J flag
• read_pstring uses from_be_bytes/from_le_bytes based on variant; subtracts prefix width when /J is set
• Parser handles /J standalone and in combinations via parse_pstring_suffix helper
• Updated codegen, strength, and all test files (13 files, +445/-100 lines)

Test Plan

• All 1,238 tests pass (877 unit + 44 integration + 34 property + 157 doc + others)
• cargo clippy -- -D warnings clean
• just ci-check passes
• New table-driven tests for BE vs LE byte order
• New tests for /J flag with all width variants
• Edge cases: /J where length equals prefix width (empty string), length < prefix width (error)

Closes #171

🤖 Generated with Claude Code

[coderabbitai]

Important

Review skipped

Auto reviews are limited based on label configuration.

🏷️ Required labels (at least one) (3)

• rust
• testing
• compatibility

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 14d79d44-cb0d-48c7-afbf-30af8627ee8d

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• ✅ Review completed - (🔄 Check again to review again)

📝 Walkthrough

Walkthrough

Add multi-width Pascal-string (pstring) support: new PStringLengthWidth enum, extended TypeKind::PString with length_width and length_includes_itself, parser suffix parsing, evaluator read_pstring to handle 1/2/4‑byte prefixes with endianness and /J semantics, plus tests and docs updates.

Changes

Cohort / File(s)	Summary
Parser AST src/parser/ast.rs	Add PStringLengthWidth enum and extend TypeKind::PString with length_width and length_includes_itself.
Parser Grammar & Types src/parser/grammar/mod.rs, src/parser/types.rs, src/parser/grammar/tests.rs, src/parser/types.rs	Add parse_pstring_suffix to parse /B//H//h//L//l and optional /J; update parsing to set new fields; update/add unit tests for suffixes.
Parser Codegen src/parser/codegen.rs	Emit new pstring fields in generated code; add helper to serialize PStringLengthWidth.
Evaluator: string reading src/evaluator/types/string.rs, src/evaluator/types/mod.rs	Change read_pstring signature to accept length_width and length_includes_itself; implement variable-width prefix read (BE/LE), /J adjustment, bounds and underflow checks; forward fields from dispatcher.
Evaluator: other src/evaluator/strength.rs, src/evaluator/engine/tests.rs	Adjust strength match to ignore added PString fields; update tests to instantiate new PString shape.
Tests / Build helpers src/build_helpers.rs, src/evaluator/engine/tests.rs	Update unit tests and serialized expectations to include new pstring fields.
Documentation & Guides docs/src/*, AGENTS.md, CONTRIBUTING.md, GOTCHAS.md	Document new pstring width/endian flags and /J; add GOTCHAS and cross-references; update examples and architecture/docs.
Repo config / manifests .coderabbit.yaml, .mcp.json, tessl.json	Update CodeRabbit review config paths and auto-review settings; add MCP server config and a vendored manifest.

Sequence Diagram

sequenceDiagram
    participant Client as CLI/Parser
    participant Grammar as Grammar<br/>(parse_pstring_suffix)
    participant AST as AST<br/>(TypeKind::PString)
    participant Evaluator as Evaluator
    participant Reader as StringReader<br/>(read_pstring)
    participant Buffer as Buffer

    Client->>Grammar: parse "pstring/H/J" token
    Grammar->>Grammar: detect "pstring" and call parse_pstring_suffix
    Grammar->>AST: construct TypeKind::PString { length_width, length_includes_itself }
    AST-->>Client: return TypeKind

    Client->>Evaluator: evaluate rule with TypeKind::PString
    Evaluator->>Reader: read_pstring(buffer, offset, max_length, length_width, length_includes_itself)
    Reader->>Buffer: read N prefix bytes (N = length_width.byte_count())
    Buffer-->>Reader: prefix bytes
    Reader->>Reader: parse length (BE/LE), apply /J adjust
    Reader->>Buffer: slice string bytes according to computed length
    Buffer-->>Reader: string bytes
    Reader-->>Evaluator: return Value::String or TypeReadError

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~35 minutes

Possibly related PRs

• feat(parser): implement pstring (Pascal string) type #170 — prior work on basic pstring support; this PR extends that surface to multi-width and /J semantics.
• refactor(evaluator): reorganize types module into submodules #156 — refactors evaluator types into submodules; overlaps with read_pstring and dispatcher changes.
• feat(parser): implement quad 64-bit integer type with endian variants #133 — related parser/evaluator/codegen adjustments affecting TypeKind and serialization.

Suggested labels

parser

Poem

🧵 Pascal strings learn to stretch and bend,
One, two, four bytes signal where contents end.
/H and /L now speak in ordered bytes,
/J counts the prefix in its little rites—
Safe slices, clearer rules, the parser’s friend. ✨

🚥 Pre-merge checks | ✅ 10

✅ Passed checks (10 passed)

Check name	Status	Explanation
Title check	✅ Passed	The PR title follows Conventional Commits spec with type(scope): description format, correctly using 'feat' type and 'parser' scope, and clearly summarizes the main feature implementation of pstring multi-byte variants.
Description check	✅ Passed	The PR description is comprehensive and directly related to the changeset, detailing implementation of pstring multi-byte prefixes, test coverage, and linking to issue #171.
Linked Issues check	✅ Passed	All acceptance criteria from issue #171 are met: PStringLengthWidth enum added, TypeKind::PString extended with length fields, parser recognizes /B/H/h/L/l/J suffixes, evaluator handles multi-byte prefixes with correct endianness, bounds checking implemented, unit tests added, and documentation updated.
Out of Scope Changes check	✅ Passed	All changes are tightly scoped to pstring multi-byte prefix support. Configuration/documentation updates to .coderabbit.yaml, AGENTS.md, CONTRIBUTING.md, GOTCHAS.md, and tessl.json/.mcp.json are supportive infrastructure changes directly related to the feature, not out-of-scope.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 85.00%.
Memory-Safety-Check	✅ Passed	No unsafe blocks, raw pointers, transmute calls, or get_unchecked patterns detected across all modified files.
Libmagic-Compatibility-Check	✅ Passed	The implementation correctly maps endianness conventions (uppercase=big-endian, lowercase=little-endian), uses proper byte order functions (from_be_bytes/from_le_bytes), implements all width variants with comprehensive test coverage, and maintains GNU libmagic compatibility throughout.
Performance-Regression-Check	✅ Passed	The pstring multi-byte length prefix implementation introduces no performance regressions, using zero-allocation string operations and efficient stack-based conversions while maintaining memory-mapped I/O compatibility.
Test-Coverage-Check	✅ Passed	Pull request demonstrates robust test coverage for pstring multi-byte length prefix feature with 68 dedicated tests across five files, comprehensive table-driven tests covering all width variants and suffix combinations, explicit edge-case testing, error handling verification with checked arithmetic, and boundary condition testing.
Error-Handling-Check	✅ Passed	Library code implements proper error handling with Result-based APIs throughout pstring implementation, no panics or unwrap calls in src/ directory.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch 171-parser-implement-pstring-multi-byte-length-prefix-variants-b-h-l

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[mergify]

Merge Protections

Your pull request matches the following merge protections and will not be merged until they are valid.

🟢 CI must pass

Wonderful, this rule succeeded.

All CI checks must pass. Release-plz PRs are exempt because they only bump versions and changelogs (code was already tested on main), and GITHUB_TOKEN-triggered force-pushes suppress CI.

• check-success = coverage
• check-success = quality
• check-success = test
• check-success = test-cross-platform (macos-latest, macOS)
• check-success = test-cross-platform (ubuntu-22.04, Linux)
• check-success = test-cross-platform (ubuntu-latest, Linux)
• check-success = test-cross-platform (windows-latest, Windows)

🟢 Do not merge outdated PRs

Wonderful, this rule succeeded.

Make sure PRs are within 10 commits of the base branch before merging

• #commits-behind <= 3

[dosubot]

Related Documentation

6 document(s) may need updating based on files changed in this PR:

libMagic-rs

architecture /libmagic-rs/blob/main/docs/src/architecture.md

View Suggested Changes

@@ -65,6 +65,7 @@
 - ✅ **Offset parsing**: Absolute offsets with comprehensive validation
 - ✅ **Operator parsing**: Equality (`=`, `==`), inequality (`!=`, `<>`), comparison (`<`, `>`, `<=`, `>=`), bitwise (`&`, `^`, `~`), and any-value (`x`) operators
 - ✅ **Value parsing**: Strings, numbers, and hex byte sequences with escape sequences
+- ✅ **PString suffixes**: `/B`, `/H`, `/h`, `/L`, `/l` (length prefix width), `/J` (self-inclusive length)
 - ✅ **Error handling**: Comprehensive nom error handling with meaningful messages
 - ✅ **Rule parsing**: Complete rule parsing via `parse_magic_rule()`
 - ✅ **File parsing**: Complete magic file parsing with `parse_text_magic_file()`
@@ -95,7 +96,11 @@
     Long { endian: Endianness, signed: bool },
     Quad { endian: Endianness, signed: bool },
     String { max_length: Option<usize> },
-    PString { max_length: Option<usize> }, // Pascal string (length-prefixed)
+    PString {
+        max_length: Option<usize>,
+        length_width: PStringLengthWidth,
+        length_includes_itself: bool,
+    }, // Pascal string (length-prefixed)
 }
 
 pub enum Operator {
@@ -111,6 +116,14 @@
     BitwiseNot,                   // ~
     AnyValue,                     // x (always matches)
 }
+
+pub enum PStringLengthWidth {
+    OneByte,                      // 1-byte prefix (default, /B)
+    TwoByteBE,                    // 2-byte big-endian prefix (/H)
+    TwoByteLE,                    // 2-byte little-endian prefix (/h)
+    FourByteBE,                   // 4-byte big-endian prefix (/L)
+    FourByteLE,                   // 4-byte little-endian prefix (/l)
+}
 ```
 
 **Design Principles:**
@@ -120,6 +133,18 @@
 - **Self-contained**: No external dependencies in AST nodes
 - **Type-safe**: Rust's type system prevents invalid rule combinations
 - **Explicit signedness**: `TypeKind::Byte` and integer types (Short, Long, Quad) distinguish signed from unsigned interpretations
+
+**PString Length Prefix Support:**
+
+The `PString` type supports multiple length prefix formats through the `length_width` field:
+
+- **OneByte** (`/B`): Default 1-byte length prefix (0-255 range)
+- **TwoByteBE** (`/H`): 2-byte big-endian prefix
+- **TwoByteLE** (`/h`): 2-byte little-endian prefix
+- **FourByteBE** (`/L`): 4-byte big-endian prefix
+- **FourByteLE** (`/l`): 4-byte little-endian prefix
+
+The `length_includes_itself` field (controlled by the `/J` suffix) indicates JPEG-style self-inclusive length, where the stored length value includes the length field itself. This can be combined with any width variant (e.g., `/HJ` for 2-byte big-endian with self-inclusive length).
 
 ### 3. Evaluator Module (`src/evaluator/`)
 
@@ -134,7 +159,7 @@
 - `types/`: Type interpretation submodule
   - `mod.rs`: Public API surface with `read_typed_value`, `coerce_value_to_type`, and type re-exports
   - `numeric.rs`: Numeric type handling (`read_byte`, `read_short`, `read_long`, `read_quad`) with endianness and signedness support
-  - `string.rs`: String type handling (`read_string`) with null-termination and UTF-8 conversion
+  - `string.rs`: String type handling (`read_string`, `read_pstring`) with null-termination, UTF-8 conversion, and multi-byte length prefix support
   - `tests.rs`: Module tests
 - `offset/`: Offset resolution submodule
   - `mod.rs`: Dispatcher (`resolve_offset`) and re-exports

✅ Accepted

ast-structures /libmagic-rs/blob/main/docs/src/ast-structures.md

View Suggested Changes

@@ -186,7 +186,11 @@
     String { max_length: Option<usize> },
 
     /// Pascal string (length-prefixed)
-    PString { max_length: Option<usize> },
+    PString {
+        max_length: Option<usize>,
+        length_width: PStringLengthWidth,
+        length_includes_itself: bool,
+    },
 }
 ```
 
@@ -231,34 +235,91 @@
 
 ### PString (Pascal String)
 
-Pascal-style length-prefixed strings where the first byte contains the string length.
+Pascal-style length-prefixed strings where the length prefix can be 1, 2, or 4 bytes depending on the `length_width` field.
 
 **Structure:**
-- Length byte: 1 byte indicating string length (0-255)
-- String data: The number of bytes specified by the length byte
+- Length prefix: 1, 2, or 4 bytes indicating string length, with configurable endianness
+- String data: The number of bytes specified by the length prefix
 
 **Example:**
 ```
 0    pstring    JPEG
-```
-Reads one byte as length, then reads that many bytes as a string.
+0    pstring/H  JPEG
+```
+The first line reads a 1-byte length prefix (default), then reads that many bytes as a string. The second line reads a 2-byte big-endian length prefix.
 
 **Behavior:**
 - Returns `Value::String` containing the string data (without the length prefix)
-- Performs bounds checking on both the length byte and the string data
+- Performs bounds checking on both the length prefix and the string data
 - Supports all string comparison operators
-
-**Usage:**
-
-```rust
-// Pascal string with no length limit
-let pstring_type = TypeKind::PString {
-    max_length: None
-};
-
-// Pascal string with maximum 64-byte limit
+- Length prefix width controlled by `PStringLengthWidth` enum
+- Optional `/J` flag indicates JPEG-style self-inclusive length (stored length includes the prefix itself)
+
+### PStringLengthWidth Enum
+
+The `PStringLengthWidth` enum specifies the width and endianness of the length prefix:
+
+```rust
+pub enum PStringLengthWidth {
+    /// 1-byte length prefix (default, `/B` suffix)
+    OneByte,
+    /// 2-byte big-endian length prefix (`/H` suffix)
+    TwoByteBE,
+    /// 2-byte little-endian length prefix (`/h` suffix)
+    TwoByteLE,
+    /// 4-byte big-endian length prefix (`/L` suffix)
+    FourByteBE,
+    /// 4-byte little-endian length prefix (`/l` suffix)
+    FourByteLE,
+}
+```
+
+**Suffix conventions:**
+- `/B` - 1-byte length prefix (default if no suffix specified)
+- `/H` - 2-byte big-endian length prefix
+- `/h` - 2-byte little-endian length prefix
+- `/L` - 4-byte big-endian length prefix
+- `/l` - 4-byte little-endian length prefix
+- `/J` - Length includes the prefix width itself (combinable: `/HJ`, `/lJ`, etc.)
+
+**Examples:**
+
+```rust
+use libmagic_rs::parser::ast::{TypeKind, PStringLengthWidth};
+
+// 1-byte length prefix (default)
+let pstring_default = TypeKind::PString {
+    max_length: None,
+    length_width: PStringLengthWidth::OneByte,
+    length_includes_itself: false,
+};
+
+// 2-byte big-endian length prefix
+let pstring_be = TypeKind::PString {
+    max_length: None,
+    length_width: PStringLengthWidth::TwoByteBE,
+    length_includes_itself: false,
+};
+
+// 4-byte little-endian length prefix
+let pstring_le = TypeKind::PString {
+    max_length: None,
+    length_width: PStringLengthWidth::FourByteLE,
+    length_includes_itself: false,
+};
+
+// 2-byte big-endian with /J flag (JPEG-style self-inclusive length)
+let pstring_jpeg = TypeKind::PString {
+    max_length: None,
+    length_width: PStringLengthWidth::TwoByteBE,
+    length_includes_itself: true,
+};
+
+// Maximum 64-byte limit with 1-byte prefix
 let limited_pstring = TypeKind::PString {
-    max_length: Some(64)
+    max_length: Some(64),
+    length_width: PStringLengthWidth::OneByte,
+    length_includes_itself: false,
 };
 ```
 

✅ Accepted

evaluator /libmagic-rs/blob/main/docs/src/evaluator.md

View Suggested Changes

@@ -34,7 +34,7 @@
   - **`types/numeric.rs`** - Numeric type handling: `read_byte`, `read_short`, `read_long`, `read_quad` with endianness and signedness support
   - **`types/float.rs`** - Floating-point type handling: `read_float` (32-bit IEEE 754), `read_double` (64-bit IEEE 754) with endianness support
   - **`types/date.rs`** - Date and timestamp type handling: `read_date` (32-bit Unix timestamps), `read_qdate` (64-bit Unix timestamps) with endianness and UTC/local time support
-  - **`types/string.rs`** - String type handling: `read_string` with null-termination and UTF-8 conversion
+  - **`types/string.rs`** - String type handling: `read_string` with null-termination and UTF-8 conversion, `read_pstring` with configurable length-prefix widths (1, 2, or 4 bytes)
   - **`types/tests.rs`** - Module tests
 - **`evaluator/strength.rs`** - Rule strength calculation
 
@@ -118,6 +118,7 @@
 - **Date**: 32-bit Unix timestamps (signed seconds since epoch) with configurable endianness and UTC/local time formatting
 - **QDate**: 64-bit Unix timestamps (signed seconds since epoch) with configurable endianness and UTC/local time formatting
 - **String**: Byte sequences with length limits
+- **PString**: Pascal-style length-prefixed strings with 1-byte (`/B`), 2-byte (`/H` or `/h`), or 4-byte (`/L` or `/l`) length prefixes, supporting big-endian and little-endian byte order
 - **Bounds checking**: Prevents buffer overruns
 
 ```rust
@@ -174,6 +175,34 @@
 - Both support UTC or local time formatting
 - The evaluator reads raw integer timestamps from the buffer and converts them to formatted date strings for comparison
 - Example: A 32-bit value `1234567890` at offset 0 with type `ldate` would be evaluated as `"Fri Feb 13 23:31:30 2009"`
+
+**Pascal String Type Reading (`evaluator/types/string.rs`):**
+
+```rust
+pub fn read_pstring(
+    buffer: &[u8],
+    offset: usize,
+    max_length: Option<usize>,
+    length_width: PStringLengthWidth,
+    length_includes_itself: bool,
+) -> Result<Value, TypeReadError>
+```
+
+- `read_pstring()` reads a length-prefixed Pascal string with configurable prefix width
+- **Length prefix width** (`length_width`):
+  - `PStringLengthWidth::OneByte` - 1-byte length prefix (`/B` suffix, default)
+  - `PStringLengthWidth::TwoByteBE` - 2-byte big-endian length prefix (`/H` suffix)
+  - `PStringLengthWidth::TwoByteLE` - 2-byte little-endian length prefix (`/h` suffix)
+  - `PStringLengthWidth::FourByteBE` - 4-byte big-endian length prefix (`/L` suffix)
+  - `PStringLengthWidth::FourByteLE` - 4-byte little-endian length prefix (`/l` suffix)
+- **Length interpretation**: 
+  - Reads 1, 2, or 4 bytes from buffer using `from_be_bytes` or `from_le_bytes` depending on variant
+  - The length value specifies how many bytes of string data follow the prefix
+- **`/J` flag** (`length_includes_itself`):
+  - When `true`, the stored length value includes the prefix width itself (JPEG-style)
+  - The evaluator subtracts the prefix width (1, 2, or 4 bytes) from the length to get effective content length
+  - Example: A 2-byte big-endian prefix with value `7` and `/J` flag yields `7 - 2 = 5` bytes of string content
+- Returns `Value::String` with UTF-8 conversion (using lossy conversion for invalid UTF-8)
 
 ### Operator Application (`evaluator/operators.rs`)
 
@@ -486,11 +515,42 @@
 assert_eq!(matches[0].message, "Pi constant detected");
 ```
 
+**Example with pstring types:**
+
+```rust
+use libmagic_rs::{evaluate_rules, EvaluationConfig};
+use libmagic_rs::parser::parse_text_magic_file;
+
+// Parse magic rules with pstring variants
+let magic_content = r#"
+0 pstring/B MAGIC Pascal string (1-byte prefix)
+0 pstring/H =\x00\x05MAGIC Pascal string (2-byte BE prefix)
+0 pstring/h =\x05\x00MAGIC Pascal string (2-byte LE prefix)
+0 pstring/L =\x00\x00\x00\x05MAGIC Pascal string (4-byte BE prefix)
+0 pstring/l =\x05\x00\x00\x00MAGIC Pascal string (4-byte LE prefix)
+"#;
+let rules = parse_text_magic_file(magic_content)?;
+
+// 1-byte prefix: length=5, then "MAGIC"
+let buffer = b"\x05MAGIC";
+let matches = evaluate_rules(&rules, &buffer)?;
+assert_eq!(matches[0].message, "Pascal string (1-byte prefix)");
+
+// 2-byte big-endian prefix with /J flag: stored length 7 (includes 2-byte prefix), effective content 5 bytes
+let magic_content_j = r#"
+0 pstring/HJ =MAGIC JPEG-style pstring with self-inclusive length
+"#;
+let rules_j = parse_text_magic_file(magic_content_j)?;
+let buffer_j = b"\x00\x07MAGIC"; // 2-byte BE prefix: value 7, minus 2 = 5 bytes of content
+let matches_j = evaluate_rules(&rules_j, &buffer_j)?;
+assert_eq!(matches_j[0].message, "JPEG-style pstring with self-inclusive length");
+```
+
 ## Implementation Status
 
 - [x] Basic evaluation engine structure
 - [x] Offset resolution (absolute, relative, from-end)
-- [x] Type reading with endianness support (Byte, Short, Long, Quad, Float, Double, Date, QDate, String)
+- [x] Type reading with endianness support (Byte, Short, Long, Quad, Float, Double, Date, QDate, String, PString with 1/2/4-byte prefixes)
 - [x] Operator application (Equal, NotEqual, LessThan, GreaterThan, LessEqual, GreaterEqual, BitwiseAnd, BitwiseAndMask)
 - [x] Hierarchical rule processing with child evaluation
 - [x] Error handling with graceful degradation

✅ Accepted

magic-format /libmagic-rs/blob/main/docs/src/magic-format.md

View Suggested Changes

@@ -227,13 +227,57 @@
 
 ### Pascal String Type
 
-Pascal string (pstring) is a length-prefixed string type. The first byte contains the string length (0-255), followed by that many bytes of string data. Unlike C strings, Pascal strings are not null-terminated.
+Pascal string (pstring) is a length-prefixed string type. The length prefix can be 1, 2, or 4 bytes depending on the suffix flag. Unlike C strings, Pascal strings are not null-terminated.
+
+#### Length Prefix Width
+
+The default pstring type uses a 1-byte length prefix (0-255 range). Use suffix flags to specify different prefix widths:
+
+| Suffix | Width   | Endianness    | Range           |
+| ------ | ------- | ------------- | --------------- |
+| `/B`   | 1 byte  | N/A           | 0-255 (default) |
+| `/H`   | 2 bytes | big-endian    | 0-65535         |
+| `/h`   | 2 bytes | little-endian | 0-65535         |
+| `/L`   | 4 bytes | big-endian    | 0-4294967295    |
+| `/l`   | 4 bytes | little-endian | 0-4294967295    |
+
+#### Self-Inclusive Length (`/J` Flag)
+
+The `/J` flag indicates that the stored length value includes the size of the length prefix itself (JPEG-style). This flag can be combined with any width variant.
+
+#### Examples
+
+Basic pstring with default 1-byte prefix:
 
 ```text
 0       pstring   =JPEG     JPEG image (Pascal string)
 ```
 
-The evaluator reads the length byte, then reads that many bytes as string data. The optional max_length parameter caps the length byte value:
+2-byte big-endian length prefix:
+
+```text
+0       pstring/H =JPEG     JPEG image (2-byte BE prefix)
+```
+
+4-byte little-endian length prefix:
+
+```text
+0       pstring/l x         \b, name: %s
+```
+
+Self-inclusive length with 2-byte big-endian prefix:
+
+```text
+0       pstring/HJ x        \b, JPEG-style length
+```
+
+Self-inclusive length with default 1-byte prefix:
+
+```text
+0       pstring/J  x        \b, self-inclusive length
+```
+
+The optional max_length parameter caps the length value:
 
 ```text
 0       pstring   x         \b, name: %s

✅ Accepted

MAGIC_FORMAT /libmagic-rs/blob/main/docs/MAGIC_FORMAT.md

View Suggested Changes

@@ -188,15 +188,37 @@
 
 **Pascal String (pstring)**
 
-Length-prefixed string type where the first byte contains the string length (0-255), followed by that many bytes of string data. Unlike C strings, Pascal strings are not null-terminated.
-
-```text
-0       pstring   =JPEG     JPEG image (Pascal string)
-```
-
-The length byte value determines how many bytes to read for the string data. If `max_length` is specified in the magic file (not shown in the basic syntax), it caps the length byte value to prevent reading excessive data.
+Length-prefixed string type where a length prefix (1, 2, or 4 bytes) specifies the number of bytes of string data that follow. Unlike C strings, Pascal strings are not null-terminated.
+
+The length prefix width is controlled by suffix flags:
+
+| Suffix | Length Prefix Width | Byte Order    |
+| ------ | ------------------- | ------------- |
+| `/B`   | 1 byte (default)    | N/A           |
+| `/H`   | 2 bytes             | big-endian    |
+| `/h`   | 2 bytes             | little-endian |
+| `/L`   | 4 bytes             | big-endian    |
+| `/l`   | 4 bytes             | little-endian |
+
+The `/J` flag indicates JPEG-style self-inclusive length where the stored length value includes the size of the length prefix itself. This flag can be combined with any width suffix (`/HJ`, `/lJ`, etc.) or used alone (`/J` defaults to 1-byte width).
+
+Examples:
+
+```text
+0       pstring   =JPEG         JPEG image (1-byte prefix, default)
+0       pstring/B =JPEG         JPEG image (1-byte prefix, explicit)
+0       pstring/H =JPEG         JPEG image (2-byte big-endian prefix)
+0       pstring/h =JPEG         JPEG image (2-byte little-endian prefix)
+0       pstring/L =JPEG         JPEG image (4-byte big-endian prefix)
+0       pstring/l =JPEG         JPEG image (4-byte little-endian prefix)
+0       pstring/HJ =JPEG        JPEG image (2-byte BE, self-inclusive length)
+```
+
+If `max_length` is specified in the magic file (not shown in the basic syntax), it caps the length value to prevent reading excessive data.
 
 ### String Flags
+
+Flags for `string` type:
 
 | Flag | Description            |
 | ---- | ---------------------- |
@@ -209,6 +231,8 @@
 ```text
 0       string/c  <!doctype  HTML document
 ```
+
+Flags for `pstring` type are documented in the Pascal String section above.
 
 ### Date/Timestamp Types
 

✅ Accepted

parser /libmagic-rs/blob/main/docs/src/parser.md

View Suggested Changes

@@ -186,40 +186,77 @@
 
 ### Pascal String (pstring) Type
 
-The parser supports Pascal-style length-prefixed strings through the `pstring` keyword:
+The parser supports Pascal-style length-prefixed strings through the `pstring` keyword with multiple length prefix width variants:
 
 **Type Keyword:**
 
-- `pstring` - Length-prefixed string (1-byte length + string data) → `TypeKind::PString { max_length: None }`
+- `pstring` - Length-prefixed string → `TypeKind::PString { max_length: None, length_width: PStringLengthWidth::OneByte, length_includes_itself: false }`
+
+**Length Prefix Width Variants:**
+
+Pascal strings support multiple length prefix widths via suffix modifiers:
+
+- `/B` - 1-byte length prefix (default) → `PStringLengthWidth::OneByte`
+- `/H` - 2-byte big-endian length prefix → `PStringLengthWidth::TwoByteBE`
+- `/h` - 2-byte little-endian length prefix → `PStringLengthWidth::TwoByteLE`
+- `/L` - 4-byte big-endian length prefix → `PStringLengthWidth::FourByteBE`
+- `/l` - 4-byte little-endian length prefix → `PStringLengthWidth::FourByteLE`
+
+**Self-Inclusive Length Flag (`/J`):**
+
+The `/J` flag indicates JPEG-style self-inclusive length, where the stored length value includes the length prefix bytes themselves. The evaluator subtracts the prefix width from the stored length to determine the actual string data length.
+
+The `/J` flag can be combined with any width variant:
+
+- `/J` - 1-byte self-inclusive (default width)
+- `/BJ` - 1-byte self-inclusive (explicit)
+- `/HJ` - 2-byte big-endian self-inclusive
+- `/hJ` - 2-byte little-endian self-inclusive
+- `/LJ` - 4-byte big-endian self-inclusive
+- `/lJ` - 4-byte little-endian self-inclusive
 
 **Format:**
 
-Pascal strings store the length as the first byte (0-255), followed by that many bytes of string data. Unlike C strings, they are not null-terminated.
+Pascal strings store the length as a prefix (1, 2, or 4 bytes depending on the variant), followed by that many bytes of string data. Unlike C strings, they are not null-terminated. When the `/J` flag is used, the length value includes the prefix size itself.
 
 **Parser Implementation:**
 
 - Recognized by `parse_type_keyword()` in `src/parser/types.rs`
-- Maps to `TypeKind::PString` in the AST
-- Evaluator reads length prefix byte then that many bytes as string data
+- Suffix parsing handled by `parse_pstring_suffix()` in `src/parser/grammar/mod.rs`
+- Maps to `TypeKind::PString` in the AST with `length_width` and `length_includes_itself` fields
+- Evaluator reads length prefix using appropriate byte order (`from_be_bytes` or `from_le_bytes`)
 - Stored as `Value::String` for comparison with string operators
-- Supports optional `max_length` field to cap the length byte value
+- Supports optional `max_length` field to cap the length value
 
 **Usage in Magic Rules:**
 
 ```rust
-// Basic pstring matching
+// Basic pstring matching (1-byte length prefix)
 0 pstring =Hello     // Match if pstring equals "Hello"
 0 pstring x          // Match any pstring value
 
-// With max_length constraint (parsed separately)
-0 pstring/64 x       // Limit string read to 64 bytes
-```
-
-**Features:**
-
-- ✅ Single type keyword `pstring`
-- ✅ Length-prefixed format (1 byte length, 0-255 bytes data)
-- ✅ Bounds checking for both length byte and string data
+// Multi-byte length prefix variants
+0 pstring/H =Test    // 2-byte big-endian length prefix
+0 pstring/h =Test    // 2-byte little-endian length prefix
+0 pstring/L =Test    // 4-byte big-endian length prefix
+0 pstring/l =Test    // 4-byte little-endian length prefix
+
+// JPEG-style self-inclusive length
+0 pstring/J x        // 1-byte self-inclusive length
+0 pstring/HJ =Data   // 2-byte big-endian self-inclusive length
+0 pstring/lJ =Data   // 4-byte little-endian self-inclusive length
+
+// With max_length constraint
+0 pstring/H/64 x     // 2-byte prefix, limit read to 64 bytes
+```
+
+**Features:**
+
+- ✅ Five length prefix width variants (1-byte, 2-byte BE/LE, 4-byte BE/LE)
+- ✅ Self-inclusive length flag (`/J`) for JPEG-style length encoding
+- ✅ Combinable suffix syntax (`/HJ`, `/lJ`, etc.)
+- ✅ Bounds checking for both length prefix and string data
+- ✅ Proper endianness handling via `from_be_bytes` / `from_le_bytes`
 - ✅ UTF-8 validation with replacement character for invalid sequences
 - ✅ Optional `max_length` parameter to limit string reads
 - ✅ String comparison operators work with pstring values

✅ Accepted

Note: You must be authenticated to accept/decline updates.

^{How did I do? Any feedback?}

[codecov]

Codecov Report

❌ Patch coverage is 95.27778% with 17 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/evaluator/types/string.rs	94.34%	13 Missing ⚠️
src/parser/codegen.rs	82.35%	3 Missing ⚠️
src/parser/types.rs	96.55%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

[coderabbitai]

Warning

CodeRabbit couldn't request changes on this pull request because it doesn't have sufficient GitHub permissions.

Please grant CodeRabbit Pull requests: Read and write permission and re-run the review.

👉 Steps to fix this

Actionable comments posted: 10

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (4)

docs/src/ast-structures.md (1)

172-190: ⚠️ Potential issue | 🟠 Major

AST docs still describe the old TypeKind::PString shape.

TypeKind::PString is documented with only max_length, but the PR adds width and /J-related semantics. Please update the enum snippet and PString section to include new fields and add a short migration note for downstream code that constructs or pattern-matches this variant.

As per coding guidelines, "Review documentation quality, completeness, and accuracy. Ensure comprehensive API documentation, usage examples, and migration guides. Focus on user experience and developer onboarding."

Also applies to: 232-267

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/src/ast-structures.md` around lines 172 - 190, Update the TypeKind enum
snippet and documentation to reflect the new PString shape: modify
TypeKind::PString to include the added fields (the new width field and the
/J-related flag/semantics introduced in the PR) and update the descriptive
paragraph for "Pascal string (length-prefixed)" to explain how width and the /J
semantics affect encoding/decoding; add a short migration note explaining how to
construct the new PString variant and how to update pattern matches (matching on
fields or using wildcard for added fields) so downstream code compiles, and
apply the same changes to the other occurrence mentioned (the block around the
later lines referenced).

docs/src/magic-format.md (1)

228-240: ⚠️ Potential issue | 🟠 Major

Magic-format reference is missing new pstring suffix grammar.

The section should document supported pstring suffixes (/B, /H, /h, /L, /l, /J, and combined forms like /HJ) with concrete examples and behavior notes. Right now readers are told only 1-byte length-prefix behavior, which is no longer accurate.

As per coding guidelines, "Review documentation quality, completeness, and accuracy. Ensure comprehensive API documentation, usage examples, and migration guides. Focus on user experience and developer onboarding."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/src/magic-format.md` around lines 228 - 240, Update the "Pascal String
Type" pstring docs to reflect the new suffix grammar: list supported suffixes
(/B, /H, /h, /L, /l, /J) and allowed combined forms (e.g., /HJ), explain how
each suffix changes the length-prefix size and endianness (e.g., /B=1-byte,
/H=/h=2-byte big/little as implemented, /L=/l=4-byte, /J=8-byte), document how
optional max_length still caps the decoded length, and add concrete examples
showing the magic lines and resulting behavior (e.g., "0 pstring/B =JPEG" vs "0
pstring/HJ x =...") so readers can see exact parsing semantics and migration
implications for code expecting 1-byte-only pstrings.

docs/src/parser.md (1)

187-226: ⚠️ Potential issue | 🟠 Major

Update pstring parser docs to match new suffix support.

This section is now stale: it documents only 1-byte pstring behavior, but parser/evaluator now support /B, /H, /h, /L, /l, and /J combinations. Please add syntax, endianness semantics, /J self-inclusive length behavior, and at least one example per width family so readers can author rules correctly.

As per coding guidelines, "Review documentation quality, completeness, and accuracy. Ensure comprehensive API documentation, usage examples, and migration guides. Focus on user experience and developer onboarding."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/src/parser.md` around lines 187 - 226, Update the "Pascal String
(pstring) Type" docs to document the new suffixes and their semantics: list the
allowed suffixes (/B, /H, /h, /L, /l, /J), explain width mapping (B=1, H=2, L=4)
and that uppercase means big-endian while lowercase means little-endian for
multi-byte length fields, and describe /J as the self-inclusive length variant
(length includes the size of the length field itself). Show the exact parsing
behavior used by parse_type_keyword() and the evaluator: how the length field is
read (with chosen width and endianness), how max_length still caps the decoded
length, how /J adjusts the resulting byte count, UTF‑8 validation/replacement,
and that values are produced as Value::String for comparisons mapped to
TypeKind::PString. Add one short usage example per width family (B, H/h, L/l)
including a /J example and one with a max_length (e.g., pstring/64), and ensure
the examples mirror the syntax the parser recognizes so readers can author rules
correctly.

src/evaluator/types/string.rs (1)

86-139: 🛠️ Refactor suggestion | 🟠 Major

Document the two new read_pstring knobs in rustdoc.

The public signature now exposes length_width and length_includes_itself, but the # Arguments section still documents only buffer, offset, and max_length, and the examples never show /J. Please add those parameters plus the underflow error case so the new behavior is discoverable in rustdoc. As per coding guidelines, "All public APIs require rustdoc with examples; include error conditions and recovery strategies; provide usage examples for common patterns."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/evaluator/types/string.rs` around lines 86 - 139, Update the rustdoc for
the public function read_pstring to document the two new parameters: add entries
in the # Arguments section for length_width (type PStringLengthWidth) and
length_includes_itself (bool) explaining their meanings and how they affect the
parsed length, and mention the underflow/error case where a length prefix that
implies fewer bytes than the header or causes negative effective payload should
return/raise TypeReadError::BufferOverrun; update the # Examples to include
calls that demonstrate different PStringLengthWidth variants (OneByte,
TwoByteBE, FourByteLE) and both values of length_includes_itself (true/false)
including an example that triggers the underflow/BufferOverrun case so the new
behavior and recovery are visible in rustdoc.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.mcp.json:
- Around line 1-12: This PR should not include the MCP server configuration;
either remove the .mcp.json entry entirely from this PR or extract it into its
own PR that adds the file plus clear documentation; specifically delete or
relocate the "mcpServers" object containing the "tessl" entry (type "stdio",
command "tessl", args ["mcp","start"]) and if moved, add a README or PR
description explaining the tessl dependency, its purpose, how it integrates with
the project, and why the MCP server is needed.

In `@AGENTS.md`:
- Around line 208-209: The pstring documentation omits the implemented /J
(self-inclusive length) suffix and its combinability with size suffixes (e.g.,
/HJ, /lJ); update the pstring sentence in AGENTS.md to state that pstring
supports 1/2/4-byte length prefixes via /B, /H (or /h), and /L (or /l) and also
supports the /J modifier which makes the length count include the length
byte(s), and note that /J can be combined with any size suffix (examples: /HJ,
/lJ) so the docs match actual behavior of pstring parsing.

In `@GOTCHAS.md`:
- Around line 94-97: Update the GOTCHAS.md section to correctly describe pstring
endianness: state that /H denotes a 2-byte big-endian length prefix and /L
denotes a 4-byte big-endian length prefix (while /h and /l remain the
little-endian counterparts), and adjust the example bytes and wording
accordingly so examples show big-endian ordering for /H and /L and little-endian
for /h and /l.

In `@src/evaluator/types/string.rs`:
- Around line 829-833: The test
test_read_pstring_j_flag_length_less_than_prefix_width is using the wrong byte
order for a TwoByteLE prefix: change the buffer used in the test (referencing
read_pstring and PStringLengthWidth::TwoByteLE) so the two-byte prefix encodes 1
in little-endian (swap the bytes to b"\x01\x00xx") to trigger the checked_sub
underflow branch; alternatively, if you prefer not to change bytes, switch the
length width to TwoByteBE so the current bytes represent 1.
- Around line 149-156: The PStringLengthWidth::OneByte branch in read_pstring
currently uses direct indexing (len_bytes[0]); change it to use safe accessor
semantics like len_bytes.get(0) and propagate the same
TypeReadError::BufferOverrun (or appropriate error) if missing, then convert the
retrieved byte to usize (e.g., usize::from(*byte)) so this branch conforms to
the repo invariant of always using .get() for buffer access.

In `@src/parser/ast.rs`:
- Around line 239-240: The PString doc comment incorrectly states the length
prefix is little-endian; update the comment for the PString type (and any
related functions/constructors named PString, parse_pstring, or similar in
ast.rs) to say the prefix endianness is configurable and can be either
little-endian or big-endian (supported by format specifiers /H, /h, /L, /l), and
describe that the length is stored in the specified endianness followed by that
many bytes of string data (not null-terminated); keep the note about 1, 2, or 4
byte lengths and mention the specifiers that control byte order so future
readers can find the supported options.
- Around line 949-958: The round-trip serialization test only covers PString
with PStringLengthWidth::OneByte and length_includes_itself: false; add
additional TypeKind::PString cases to that test exercising 2-byte and 4-byte
width variants for both endianness and a case where length_includes_itself is
true (the “/J” case). Concretely, in the existing round-trip test that builds
TypeKind::PString values, add at least: a 2-byte big-endian variant, a 2-byte
little-endian variant, a 4-byte big-endian variant, a 4-byte little-endian
variant (using the appropriate PStringLengthWidth enum variants for 2/4 bytes
and BE/LE), and one PString with length_includes_itself: true; ensure each new
instance is included in the same serialize->deserialize assertions to catch
serde shape regressions.

In `@src/parser/grammar/mod.rs`:
- Around line 727-737: The code currently consumes the '/' before validating the
pstring suffix which lets invalid suffixes like '/x' be silently accepted;
change the logic in the pstring handling block so you first attempt to
parse/validate the suffix (e.g., call or adapt parse_pstring_suffix to return a
Result or an Option without mutating input) and only update input,
pstring_length_width, and pstring_length_includes_itself when the suffix parse
succeeds; on failure, emit/collect a syntax error (with location) and leave the
input unchanged so parsing can continue. Ensure references to
parse_pstring_suffix, input, pstring_length_width, and
pstring_length_includes_itself are used to locate and implement the change.

In `@tessl.json`:
- Around line 5-7: The dependency entry for "actionbook/rust-skills" is pinned
to a raw commit hash in the "version" field which hinders maintainability;
replace the commit-hash value with a stable tag or semantic release (e.g.,
"v1.2.3") when available, and if a tag is not available document an update
policy for this vendored dependency and add an automated periodic check (CI job
or script) to verify the commit remains accessible and to alert when newer
tags/commits appear; update the "version" field accordingly and add a short
comment or README note describing the chosen update cadence and the existence of
the periodic check.
- Around line 1-40: tessl.json appears to be a development-only AI/tooling
config (contains "name": "stringy" and a pinned dependency
"actionbook/rust-skills") and should not be included in the published crate;
either move this file into a non-distributed location (e.g., .github/ or a
tools/ directory) or add tessl.json to .gitignore, correct the "name" field to
match the repository ("libmagic-rs") if you keep it, and add a short README
entry documenting why the actionbook/rust-skills dependency is needed and
whether pinning to the specific commit is intentional or should be
relaxed/removed.

---

Outside diff comments:
In `@docs/src/ast-structures.md`:
- Around line 172-190: Update the TypeKind enum snippet and documentation to
reflect the new PString shape: modify TypeKind::PString to include the added
fields (the new width field and the /J-related flag/semantics introduced in the
PR) and update the descriptive paragraph for "Pascal string (length-prefixed)"
to explain how width and the /J semantics affect encoding/decoding; add a short
migration note explaining how to construct the new PString variant and how to
update pattern matches (matching on fields or using wildcard for added fields)
so downstream code compiles, and apply the same changes to the other occurrence
mentioned (the block around the later lines referenced).

In `@docs/src/magic-format.md`:
- Around line 228-240: Update the "Pascal String Type" pstring docs to reflect
the new suffix grammar: list supported suffixes (/B, /H, /h, /L, /l, /J) and
allowed combined forms (e.g., /HJ), explain how each suffix changes the
length-prefix size and endianness (e.g., /B=1-byte, /H=/h=2-byte big/little as
implemented, /L=/l=4-byte, /J=8-byte), document how optional max_length still
caps the decoded length, and add concrete examples showing the magic lines and
resulting behavior (e.g., "0 pstring/B =JPEG" vs "0 pstring/HJ x =...") so
readers can see exact parsing semantics and migration implications for code
expecting 1-byte-only pstrings.

In `@docs/src/parser.md`:
- Around line 187-226: Update the "Pascal String (pstring) Type" docs to
document the new suffixes and their semantics: list the allowed suffixes (/B,
/H, /h, /L, /l, /J), explain width mapping (B=1, H=2, L=4) and that uppercase
means big-endian while lowercase means little-endian for multi-byte length
fields, and describe /J as the self-inclusive length variant (length includes
the size of the length field itself). Show the exact parsing behavior used by
parse_type_keyword() and the evaluator: how the length field is read (with
chosen width and endianness), how max_length still caps the decoded length, how
/J adjusts the resulting byte count, UTF‑8 validation/replacement, and that
values are produced as Value::String for comparisons mapped to
TypeKind::PString. Add one short usage example per width family (B, H/h, L/l)
including a /J example and one with a max_length (e.g., pstring/64), and ensure
the examples mirror the syntax the parser recognizes so readers can author rules
correctly.

In `@src/evaluator/types/string.rs`:
- Around line 86-139: Update the rustdoc for the public function read_pstring to
document the two new parameters: add entries in the # Arguments section for
length_width (type PStringLengthWidth) and length_includes_itself (bool)
explaining their meanings and how they affect the parsed length, and mention the
underflow/error case where a length prefix that implies fewer bytes than the
header or causes negative effective payload should return/raise
TypeReadError::BufferOverrun; update the # Examples to include calls that
demonstrate different PStringLengthWidth variants (OneByte, TwoByteBE,
FourByteLE) and both values of length_includes_itself (true/false) including an
example that triggers the underflow/BufferOverrun case so the new behavior and
recovery are visible in rustdoc.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: d45f7fed-b735-4e94-9b40-7b94b86db8cb

📥 Commits

Reviewing files that changed from the base of the PR and between 2c35b16 and 1821cc9.

⛔ Files ignored due to path filters (7)

• .codex/config.toml is excluded by none and included by none
• .gemini/settings.json is excluded by none and included by none
• .gitignore is excluded by none and included by none
• .tessl/.gitignore is excluded by none and included by none
• docs/API_REFERENCE.md is excluded by none and included by none
• tests/evaluator_tests.rs is excluded by none and included by none
• tests/property_tests.rs is excluded by none and included by none

📒 Files selected for processing (19)

• .coderabbit.yaml
• .mcp.json
• AGENTS.md
• CONTRIBUTING.md
• GOTCHAS.md
• docs/src/ast-structures.md
• docs/src/magic-format.md
• docs/src/parser.md
• src/build_helpers.rs
• src/evaluator/engine/tests.rs
• src/evaluator/strength.rs
• src/evaluator/types/mod.rs
• src/evaluator/types/string.rs
• src/parser/ast.rs
• src/parser/codegen.rs
• src/parser/grammar/mod.rs
• src/parser/grammar/tests.rs
• src/parser/types.rs
• tessl.json

💤 Files with no reviewable changes (1)

• .coderabbit.yaml

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

docs/src/parser.md (1)

187-263: ⚠️ Potential issue | 🔴 Critical

Remove unsupported max_length example from documentation.

The pstring parser does not support the /64 suffix syntax shown in the line 250 example. The test cases in src/parser/grammar/tests.rs:2138-2180 confirm the parser only handles width variants (/B, /H, /h, /L, /l) and the self-inclusive flag (/J), with max_length always initialized to None. The max_length field exists in the TypeKind::PString AST struct for programmatic use, but cannot be specified through magic rule syntax.

Remove the example 0 pstring/H/64 x from line 250 or clarify that max_length is only available when constructing rules programmatically via the Rust API.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/src/parser.md` around lines 187 - 263, Update the pstring docs to remove
the unsupported suffix example (the `0 pstring/H/64 x` line) or explicitly state
that max_length cannot be specified in magic syntax; instead note that
max_length exists only in the AST/ Rust API. Reference parse_type_keyword() and
parse_pstring_suffix() as the parser entrypoints and TypeKind::PString as the
AST variant so readers understand that only /B,/H,/h,/L,/l and /J suffixes are
parsed and that max_length is set programmatically, not via rule suffixes.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Outside diff comments:
In `@docs/src/parser.md`:
- Around line 187-263: Update the pstring docs to remove the unsupported suffix
example (the `0 pstring/H/64 x` line) or explicitly state that max_length cannot
be specified in magic syntax; instead note that max_length exists only in the
AST/ Rust API. Reference parse_type_keyword() and parse_pstring_suffix() as the
parser entrypoints and TypeKind::PString as the AST variant so readers
understand that only /B,/H,/h,/L,/l and /J suffixes are parsed and that
max_length is set programmatically, not via rule suffixes.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 46e46d0e-2016-4321-97fd-f5a090d065ee

📥 Commits

Reviewing files that changed from the base of the PR and between 1821cc9 and 0284b50.

⛔ Files ignored due to path filters (1)

• docs/MAGIC_FORMAT.md is excluded by none and included by none

📒 Files selected for processing (6)

• .coderabbit.yaml
• docs/src/architecture.md
• docs/src/ast-structures.md
• docs/src/evaluator.md
• docs/src/magic-format.md
• docs/src/parser.md