-
Notifications
You must be signed in to change notification settings - Fork 940
Improve header comment and strengthen type checking for entry #2794
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
Conversation
Signed-off-by: Jim Brunner <[email protected]>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## unstable #2794 +/- ##
============================================
+ Coverage 72.30% 72.46% +0.16%
============================================
Files 128 128
Lines 70211 70224 +13
============================================
+ Hits 50763 50888 +125
+ Misses 19448 19336 -112
🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice improvement and it does improve correctness
| /* The entry pointer is the field sds. We encode the entry layout type | ||
| * in the field SDS header. Field type SDS_TYPE_5 doesn't have any spare bits to | ||
| * encode this so we use it only for the first layout type. | ||
| /* There are 3 different formats for the "entry". In all cases, the "entry" pointer points into the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there are 4 right? expiration existence only multiply the past 2 encoding types (embedded value and non-embedded value)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In types 2 and 3, the expiration is optional. I didn't consider/document these as fundamentally different types. If we do that, there would be 5 types.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
O.K I understand it better now. LGTM
…-io#2794) In `entry.c`, the `entry` is a block of memory with variable contents. The structure can be difficult to understand. A new header comment more clearly documents the contents/layout of the `entry`. Also, in `entry.h`, the `entry` was defined by `typedef void entry`. This allows blind casting to the `entry` type. It defeats compiler type checking. Even though the `entry` has a variable definition, we can define entry as a legitimate type which allows the compiler to perform type checking. By performing `typedef struct _entry entry`, now the `entry` is understood to be a pointer to some type of undefined structure. We can pass a pointer and the compiler can typecheck the pointer. (Of course we can't dereference it, because we haven't actually defined the struct.) Signed-off-by: Jim Brunner <[email protected]>
In
entry.c, theentryis a block of memory with variable contents. The structure can be difficult to understand. A new header comment more clearly documents the contents/layout of theentry.Also, in
entry.h, theentrywas defined bytypedef void entry. This allows blind casting to theentrytype. It defeats compiler type checking.Even though the
entryhas a variable definition, we can define entry as a legitimate type which allows the compiler to perform type checking. By performingtypedef struct _entry entry, now theentryis understood to be a pointer to some type of undefined structure. We can pass a pointer and the compiler can typecheck the pointer. (Of course we can't dereference it, because we haven't actually defined the struct.)