jiridanek opened a new pull request, #450: URL: https://github.com/apache/qpid-proton/pull/450
https://issues.apache.org/jira/browse/PROTON-2957 `pn_message_decode()` only scans the wire-level section framing (header, properties, annotations, application-properties, body) and stores each section's raw, undecoded bytes on the `pn_message_t`. It never invokes the generic AMQP codec (`codec.c`, `decoder.c`) on any of that content -- that only happens lazily, the first time an application calls one of the `pn_message_instructions()`, `pn_message_annotations()`, `pn_message_properties()`, or `pn_message_body()` accessors. The `fuzz-message-decode` harness only ever called `pn_message_decode()` and discarded the result, so none of those accessors were ever invoked and the fuzzer's input never actually reached the codec. This calls the four accessors and forces a full read-side traversal of each resulting `pn_data_t` via `pn_data_format()`, then round-trips the message back to bytes via `pn_message_encode2()` to also exercise the encoder on the same content. This implements the harness's own long-standing `// FUTURE: do something like encode msg and compare again with Data` comment. ## Test plan - [x] Verified the existing regression corpus still passes unmodified (`ctest -R fuzz-message-decode`) - [x] Confirmed the harness builds and runs cleanly with `-DENABLE_FUZZ_TESTING=ON` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
