Skip to content

Conversation

@FozzTexx
Copy link
Contributor

Made the network-protocol classes be explicit about error codes. Methods now return either NETPROTO_ERR_NONE or NETPROTO_ERR_UNSPECIFIED, which removes any confusion about the old true/false behavior and whether success or failure looked "backwards." The netProtoErr_t enum still matches the previous bool usage, so existing failure-check logic did not need any changes.

Part of the process for removing cmdFrame_t from the network-protocol classes.

Made the network-protocol classes be explicit about error codes. Methods now return either NETPROTO_ERR_NONE or NETPROTO_ERR_UNSPECIFIED, which removes any confusion about the old true/false behavior and whether success or failure looked "backwards." The netProtoErr_t enum still matches the previous bool usage, so existing failure-check logic did not need any changes.
@FozzTexx FozzTexx force-pushed the feature/protocol-error branch from c9b45ef to 96352cb Compare November 10, 2025 19:15
Copy link
Collaborator

@tschak909 tschak909 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup makes sense. Thanks.

@tschak909 tschak909 merged commit 571e594 into FujiNetWIFI:master Nov 10, 2025
25 checks passed
@FozzTexx FozzTexx deleted the feature/protocol-error branch November 11, 2025 00:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants