iStats #86: CFStringGetCStringPtr usually returns null. #88
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
CFStringGetCStringPtr usually returns null. I added a fallback with CFStringGetCString to allocate a string. This is consistent and in compliance with Apple. The following link should give a bit more insight.
CFStringGetCStringPtr Obj-C doc
With this fallback type of system, older systems will still behave as they did and newer ones will get the battery string the new way. Either way, it should all work the same. The only thing I'm unclear of and maybe you can help with, is how does the freeing of the pointer work? I'm not familiar with rb_str_new2, so I don't know if the GC will clean up that pointer or not.
If there's any improvements I can make or you can shed more info on how this works, that would be great. Thanks for this great little tool, you saved me plenty of time reinventing the wheel.
p.s. Can you also give a bit more info as to how to better/quicker debug? Thanks again!