Yes, I mean in a bug situation where the second reference is not aware
that it was released.
2017-12-13 16:14 GMT-02:00 Ranier VF <[email protected]>:
> 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
>
------------------------------------------------------------------------------
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
