docs: update README and wiki API reference to reflect current functio…#64
docs: update README and wiki API reference to reflect current functio…#64
Conversation
…n signatures and return codes - README getter table: rename 'Out-param type' column to 'Output struct' and add explicit 'On success' / 'On failure' columns with the exact OkjError codes each getter returns (OKJ_ERROR_BAD_STRING, OKJ_ERROR_BAD_NUMBER, OKJ_ERROR_BAD_BOOLEAN, OKJ_ERROR_BAD_ARRAY, OKJ_ERROR_BAD_OBJECT, or OKJ_ERROR_BAD_POINTER for okj_get_token) - README utilities table: add Returns column with uint16_t and document NULL-parser behaviour (returns 0) for all three counting helpers - README Quick Start: fix okj_copy_string call to cast sizeof(buf) to uint16_t, matching the function signature - wiki/API-Reference: expand okj_parse section with a full table of possible return codes - wiki/API-Reference: add per-getter return-code table; call out that okj_get_token returns OKJ_ERROR_BAD_POINTER on not-found (unlike the type-specific codes used by the other getters); document the partial-write behaviour of okj_get_array / okj_get_object when the size limit is exceeded https://claude.ai/code/session_01NJixwcioGAPgWwSgxCUWDx
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: af52eb07b9
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| | `OKJ_SUCCESS` | Parse completed; tokens are valid | | ||
| | `OKJ_ERROR_BAD_POINTER` | `parser` is `NULL` | | ||
| | `OKJ_ERROR_MAX_JSON_LEN_EXCEEDED` | `json_len` exceeds `OKJ_MAX_JSON_LEN` | | ||
| | `OKJ_ERROR_SYNTAX` | Trailing non-whitespace after the top-level value | |
There was a problem hiding this comment.
OKJ_ERROR_SYNTAX condition
Checked src/ok_json.c:807-1492: okj_parse_value() sets OKJ_ERROR_SYNTAX for many malformed inputs besides trailing bytes after the top-level value, including misplaced ,/: tokens, malformed literal boundaries such as truex, and any otherwise unrecognized character. Presenting this row as the full condition for OKJ_ERROR_SYNTAX will cause callers to misdiagnose most real parse failures.
Useful? React with 👍 / 👎.
| | `OKJ_ERROR_INVALID_CHARACTER` | Unexpected character in the input stream | | ||
| | `OKJ_ERROR_BAD_NUMBER` | Malformed numeric literal | | ||
| | `OKJ_ERROR_BAD_STRING` | Malformed string literal | | ||
| | `OKJ_ERROR_BAD_BOOLEAN` | Malformed boolean literal | |
There was a problem hiding this comment.
I checked src/ok_json.c:807-1492, and okj_parse() never returns either OKJ_ERROR_INVALID_CHARACTER or OKJ_ERROR_BAD_BOOLEAN: unexpected bytes and malformed booleans both end up on OKJ_ERROR_SYNTAX paths. Documenting these as parse results asks downstream code to branch on statuses it cannot actually receive.
Useful? React with 👍 / 👎.
| | `okj_count_elements(parser)` | Return the total token count (`parser->token_count`) | | ||
| | Function | Returns | Description | | ||
| |----------|---------|-------------| | ||
| | `okj_copy_string(str, buf, buf_size)` | `uint16_t` | Copy string content into a caller-supplied buffer with NUL termination; returns bytes copied (excluding NUL), or `0` on error | |
There was a problem hiding this comment.
okj_copy_string() returns copy_len, and for a valid empty JSON string (str->length == 0) it still writes the terminator and returns 0 (src/ok_json.c:1962-1994). This new README row says 0 means error, which would make readers reject successful copies of "" values.
Useful? React with 👍 / 👎.
2 participants
…n signatures and return codes
https://claude.ai/code/session_01NJixwcioGAPgWwSgxCUWDx