Hi, "Let's say that there are two references to the memory. The memory is released, but the other reference tries to access it." For me, this is a bug. If are other references for one memory, its could not be released.
But, works for now, especially with this behavior. It is the same as: free(ptr); ptr = NULL; /* Prevents use-after-free. */ 0xFF sounds good to me too. Best. Ranier ________________________________________ De: Antonio Scuri <[email protected]> Enviado: quarta-feira, 13 de dezembro de 2017 15:43 Para: IUP discussion list. Assunto: Re: [Iup-users] Thanks for the work so far; proposed IM patch for SVN-r737 About the memset. Let's say that there are two references to the memory. The memory is released, but the other reference tries to access it. If memory is set to 0 before released, the second reference will still point to the same area, don't it? I think it is useful even when not in debug. Remember that we provide pre-compiled binaries without debug information. But the idea of using a different value, like 0xDD, could be interesting. Why not 0xFF? In a rare case this could point to a valid memory... (?) We don't do that very often, only in a few parts of the IUP code that I consider sensible for memory allocation. Best, Scuri 2017-12-13 13:35 GMT-02:00 Antonio Scuri <[email protected]<mailto:[email protected]>>: That makes sense when they are not local variables, or when the function goes on with more code after the free. At the end of the function (or just before a return) to set the local pointer to NULL seems useless. Best, Scuri 2017-12-12 20:44 GMT-02:00 sur-behoffski <[email protected]<mailto:[email protected]>>: G'day again, Thank you for your responses to the three build summaries I sent out yesterday. I've updated my Subversion repositories. Attached is a patch for im/trunk/src/process/im_analyze.cpp, which gets rid of some of the remaining "misleading indentation" warnings. The comments in the patch, as well as the paranoid "set freed stack-based pointers to NULL", are somewhat jarring relative to the general tone and flow of the overall code of the module. I would expect that some, or perhaps most, of these comments and paranoid code would not be included in the immediate future; however, they may be considered at some point. I'm using some level of paranoia in my personal code, because I am striving to stay very clean in using and freeing memory slabs and all associated memory pointers, so that it is clean when run under Valgrind. Although I've tackled a significant slab of code, there are more opportunities for this kind of rewrite in a few places, perhaps mostly further down in the same function; e.g. (line numbers are rough figures since they assume the attached patch has been applied): - Lines 834-844; - Lines 963-974; And a couple of places where we can rely on free(3) to quietly ignore NULL pointers: - Lines 707-708 ("if (local_data_cx) free(local_data_cx);"); - Line 1113 ("if (holes_perim) free(holes_perim);"). cheers, sur-behoffski programmer, Grouse Software ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Iup-users mailing list [email protected]<mailto:[email protected]> https://lists.sourceforge.net/lists/listinfo/iup-users ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Iup-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/iup-users
