Hi,
there is in gr-osmosdr a lot of code like:
hackrf_source_c::~hackrf_source_c () { ... free(_buf); _buf = NULL; } }
Setting value in destructor have sense in two case: - they are used in some way in destructor of parent class - You set then to something like 0xDEADBEEF and when pointer from already destroyed class is used it will cause segfault.
Setting value to NULL is contraproductive because there is a lot of checks if value is not NULL, this actually can hide some troubles of calling something using already freed pointer.
I'm suggesting to remove this kind of code. I will prepare patch but now I'm waiting if those two pending patches I have send before would be accepter or not.
Is there any opinion which oppose previous claim?
With best regards, JP.
Hi Jiri, i'd be happy to accept such patch.
Best regards, Dimitri
On Sun, 04 Oct 2015 15:58:53 +0200, P j-pi@seznam.cz wrote:
Hi,
there is in gr-osmosdr a lot of code like:
hackrf_source_c::~hackrf_source_c () { ... free(_buf); _buf = NULL; } }
Setting value in destructor have sense in two case:
- they are used in some way in destructor of parent class
 - You set then to something like 0xDEADBEEF and when pointer from already destroyed class is used it will cause segfault.
 Setting value to NULL is contraproductive because there is a lot of checks if value is not NULL, this actually can hide some troubles of calling something using already freed pointer.
I'm suggesting to remove this kind of code. I will prepare patch but now I'm waiting if those two pending patches I have send before would be accepter or not.
Is there any opinion which oppose previous claim?
With best regards, JP.