Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix warnings #23

Merged
merged 4 commits into from Sep 6, 2016
Merged

Fix warnings #23

merged 4 commits into from Sep 6, 2016

Conversation

gperciva
Copy link
Member

@gperciva gperciva commented Sep 3, 2016

No description provided.

kvldskey_mlen() will always return a value which fits into (uint8_t).  It
begins by setting
    size_t mlen = 0
and then increments it until
    mlen == kvldskey->(uint8_t len)
(or until the buffers do not match).  The definition of `struct kvldskey` is in
    lib/datastruct/kvldskey.h
Since the `len` field of `struct kvldskey` is uint8_t, it doesn't make sense to
accept a larger buflen.
callback_read_header() waits until it has a complete header, or waits for more
to arrive.  That seems appropriate for the end of callback_connected(), so I
don't think we need that extra return.
@@ -15,12 +15,15 @@ kvldskey_create(const uint8_t * buf, size_t len)
{
Copy link
Member Author

Choose a reason for hiding this comment

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

I was tempted to change kvldskey_create to accept uint8_t buflen instead of size_t buflen since struct kvldskey stores uint8_t, but this strikes me as a "6 of one, half a dozen of the other" situation.

Copy link
Member

Choose a reason for hiding this comment

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

Leaving the API as size_t is good. This way future bugs are more likely to be caught via the assertion rather than hidden by silent integer overflow.

@cperciva cperciva merged commit 4555190 into master Sep 6, 2016
@gperciva gperciva deleted the fix-warnings branch September 6, 2016 01:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants