Since 100614 has been merged I'm taking this discussion out of the patch manager area into here.
In reference to the eight special cases you (Charlie) mention (actually, I think I counted nine), I see two avenues off the top of my head. We could either change these back to straight [m|re]alloc() calls, or I could add a third parameter to nco_malloc() and nco_realloc(), say just an integer for example, the presence of which indicates whether the wrappers should handle error checking or just behave like the standard functions they wrap around. Then the few callers that want to do extra diagnostics themselves could pass this third parameter to tell the wrappers to step out of the way and just let malloc() and realloc() do their worst.
This is what I've come up with so far, but I'm still thinking about it and I'm open to suggestions. Thanks for your encouragement, patience, and help with 100614. In the future I'll be sure to do more thorough testing of my code before submitting it.
- Bill
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, leaving a few straight malloc() calls is fine.
So we should probably return those nine to their former state.
Anything else would involve writing another set of wrappers
for extra diagnostics. That might be useful but the extra
diagnostics are sometimes case-specific. Let's not add
arguments to nco_malloc() though, I like the elegance
of that patch the way it is. I'll be off email until Friday.
Cheers.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I agree. After some thought, it seemed a bit silly to call a wrapper and tell it to "unwrap" (the third parameter scenario). I'll change those special cases back to the standard functions and submit a patch.
Enjoy your time off...
-Bill
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Since 100614 has been merged I'm taking this discussion out of the patch manager area into here.
In reference to the eight special cases you (Charlie) mention (actually, I think I counted nine), I see two avenues off the top of my head. We could either change these back to straight [m|re]alloc() calls, or I could add a third parameter to nco_malloc() and nco_realloc(), say just an integer for example, the presence of which indicates whether the wrappers should handle error checking or just behave like the standard functions they wrap around. Then the few callers that want to do extra diagnostics themselves could pass this third parameter to tell the wrappers to step out of the way and just let malloc() and realloc() do their worst.
This is what I've come up with so far, but I'm still thinking about it and I'm open to suggestions. Thanks for your encouragement, patience, and help with 100614. In the future I'll be sure to do more thorough testing of my code before submitting it.
- Bill
Yes, leaving a few straight malloc() calls is fine.
So we should probably return those nine to their former state.
Anything else would involve writing another set of wrappers
for extra diagnostics. That might be useful but the extra
diagnostics are sometimes case-specific. Let's not add
arguments to nco_malloc() though, I like the elegance
of that patch the way it is. I'll be off email until Friday.
Cheers.
I agree. After some thought, it seemed a bit silly to call a wrapper and tell it to "unwrap" (the third parameter scenario). I'll change those special cases back to the standard functions and submit a patch.
Enjoy your time off...
-Bill