BRL-CAD provides basic memory management in our libbu utility library similar to malloc() and free() but coincidingly named bu_malloc() and bu_free().
This task involves converting all calls to bu_free() where we cast the first parameter to (char*) or (void*) and making them instead be (genptr_r) casts.
Example:
- bu_free((char *)arbp, "arb_specific");
- ...becomes...
- bu_free((genptr_t)arbp, "arb_specific");
While there are probably 1000 places this needs to be fixed, it should be relatively easy to automate with a few careful regular expressions in perl, python, sed, etc. However, be SURE to check your changes!
You should be able to compile cleanly beforehand and after. Check the entire source tree. Submit your changes as a single patch file with all changes, see http://brlcad.org/wiki/Deuces to get started and for help making patches.
| File name/URL | File size | Date submitted | |
|---|---|---|---|
| genptr_t.patch | 216.6 KB | December 13 2012 03:18 UTC |
I would like to work on this task.
This task has been assigned to javamonn. You have 72 hours to complete this task, good luck!
The work on this task is ready to be reviewed.
I haven't applied the patch yet because of other patches I'm working on, but it looks good on a quick visual read-through.
Out of curiosity, can you check and report if you get a compilation warning/failure if you simply remove all of the casts from bu_free() calls? I presume from the talk on IRC that you scripted this change, so hopefully it's something you can test easily. If it works, that'd be a good patch to have as well.
Congratulations, this task has been completed successfully.
I'll check it out when I get home later, it'll be pretty easy to take out the casts altogether. I imagine you might not run into any problems by removing them, I noticed alot of calls to bu_free() that didn't have casts.
The problem will be whether there are any places in the code where the compiler isn't happy about performing the conversion automatically from whatever the provided type is to the void* type. That is likely going to be platform-specific, but if we can get rid of most of them, it's still a win. Ones that might be a problem are where we do type punning or passing arrays or elements to arrays that might make the compiler bark. In those (few?) cases, a cast may still be needed. Make sure you compile in Release mode with strict enabled (it's the default) when you test. Thanks!
I'm still trying to work this out. I'm having problems compiling even a fresh checkout with strict enabled, its running into warnings being treated as errors around the 20% mark. I've been able to fix a couple of them but it seems like a lot of work just to see if some other edit I made compiles without problems. Is there any way I can skip past and not compile these files that are causing havok in the fresh checkout, or maybe only compile the files I edited the casts out of?
Thanks for the help,
Daniel
I cant get a fresh checkout to compile with strict off either, apparently. I'm running Ubuntu with the gcc compiler.
It should work straight from a checkout, but there has been a lot of GCI-related commits recently that may have introduced a few minor warnings. Those sorts of issues are usually cleared up in a day or two, but you could just try to run "make -k" and review whether any of the warning/errors are related to bu_free(). If this is looking like it'll take a couple hours, we can just create another task.