Timeline for Simple key-value store in C, take 2
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 23, 2014 at 0:11 | comment | added | Corbin | I think it's much more fitting of the philosophy of C to trust the user to handle his own safeguard if he wants them. It doesn't only encumber the interface, but it also would impose a (very, very minor) performance penalty. @Dagg I've never used a library that nulled free'd pointer, but my use of C libraries is pretty limited, so who knows how much that means. | |
| Sep 22, 2014 at 17:37 | comment | added | Dagg | @syb0rg is it really necessary to document what a function won't do, especially if it's obvious that it can't do that given its signature? Now I'm curious what other projects do when they need C-destructors. | |
| Sep 22, 2014 at 16:18 | comment | added | syb0rg | @Corbin The trade-off's of writing an API: making it safer and more cumbersome, or giving the user more freedom. I feel like if Dagg does choose to go that route, there should be documentation telling the user that. | |
| Sep 22, 2014 at 16:16 | comment | added | Corbin | @syb0rg In that case, I agree with Dagg; it's not worth making the API more cumbersome just to ensure that the user doesn't misuse the API, especially since the user could just NULL it out himself, or write a simple wrapper to do it. | |
| Sep 22, 2014 at 16:16 | history | edited | syb0rg | CC BY-SA 3.0 |
added 119 characters in body
|
| Sep 22, 2014 at 16:15 | comment | added | syb0rg | @Corbin Yes, that is what I meant. I will re-word my answer to reflect that. | |
| Sep 21, 2014 at 23:39 | comment | added | Dagg |
@Corbin that's what I was thinking... wouldn't it be the caller's responsibility to set store = NULL after calling kvs_destroy(store)? Setting the local variable to NULL inside of kvs_destroy doesn't affect the copy of the pointer that was passed in. Using a double pointer just to be able to NULL it seems like overkill.
|
|
| Sep 21, 2014 at 23:10 | comment | added | Corbin | Setting the struct member to null post-release doesn't really accomplish much unless the pointer to the struct is also nulled. The dereference of the struct pointer would give you a segfault before the member could ever be touched. (Or were you saying he should change the function signature to take a double pointer and that he should free the pointer to struct?) | |
| Sep 21, 2014 at 19:49 | comment | added | ChrisWue |
Actually in production level code you often see if (NULL == pointer) to protect against accidental typos of = instead of ==. These days most compilers will spit out a warning for that but it's a habit you might want to consider getting into
|
|
| Sep 21, 2014 at 18:45 | comment | added | Dagg |
All of my other null checks are done the way you suggest, but for some reason foo == NULL seemed more appropriate there. I guess I should use the same style everywhere though.
|
|
| Sep 21, 2014 at 18:42 | history | answered | syb0rg | CC BY-SA 3.0 |