Ok, I pulled up the rest of the code and now I understand what you mean: There are accesses to base after dup has been freed. Yeah, I would delay freeing dup until nobody is using neither it nor base.
On Sat, 20 Apr 2019, 1:36 pm Simon Mages, <[email protected]> wrote: > if base and dup are the same pointer or pointing into the same allocation, > then a free on one of them will free the other one as well. > > On Sat, 20 Apr 2019, 11:27 Xavi Artigas, <[email protected]> wrote: > >> Sure, base should not be freed, but dup must be for sure, no? >> >> Anyway, this is simple enough to check with a test case and valgrind :) >> >> On Sat, 20 Apr 2019, 11:14 am Simon Mages, <[email protected]> >> wrote: >> >>> Well, >>> >>> dup and base can be the same pointer. >>> >>> BR >>> >>> On Sat, 20 Apr 2019, 11:07 Xavi Artigas, <[email protected]> >>> wrote: >>> >>>> Hi, >>>> >>>> Nobody is freeing what basename returns, right? Or am I reading it >>>> wrong? >>>> (I am not in front of the computer) >>>> >>>> Xavi >>>> >>>> On Fri, 19 Apr 2019, 5:44 pm Simon Mages via enlightenment-devel, < >>>> [email protected]> wrote: >>>> >>>>> Hi there, >>>>> >>>>> i tried to compile efl on a somewhat hardened linux. >>>>> >>>>> >>>>> https://github.com/Enlightenment/efl/blob/master/src/bin/eolian_cxx/eolian_cxx.cc >>>>> >>>>> """ >>>>> char* dup = strdup(opts.in_files[0].c_str()); >>>>> char* base = basename(dup); >>>>> std::string cpp_types_header; >>>>> opts.unit = (Eolian_Unit*)opts.state; >>>>> klass = ::eolian_state_class_by_file_get(opts.state, base); >>>>> free(dup); >>>>> """ >>>>> >>>>> basename(3): >>>>> ... >>>>> These functions may return pointers to statically allocated memory >>>>> which may be overwritten by subsequent calls. Alternatively, they may >>>>> return a pointer to some part of path, so that the string referred to >>>>> by path should not be modified or freed until the pointer returned by >>>>> the function is no longer required. >>>>> ... >>>>> >>>>> As far as i understand the string share structure, this call to free >>>>> should not be there. Somewhere else in the file there is similar case. >>>>> Sorry for not sending a diff, but i hope that helps anyway. >>>>> >>>>> BR >>>>> Simon >>>>> >>>>> >>>>> _______________________________________________ >>>>> enlightenment-devel mailing list >>>>> [email protected] >>>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >>>>> >>>> _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
