El Dilluns, 27 d'agost de 2012, a les 22:31:13, Albert Astals Cid va escriure: > El Dilluns, 27 d'agost de 2012, a les 08:29:40, Thomas Freitag va escriure: > > On 27.08.2012 00:56, Albert Astals Cid wrote: > > > El Diumenge, 26 d'agost de 2012, a les 15:48:37, He Liu va escriure: > > >>>> 5. vtable pointer will be overwritten > > >>>> Function.cc:422:10: warning: destination for this 'memcpy' call is a > > >>>> pointer to dynamic class 'SampledFunction'; vtable pointer will be > > >>>> overwritten [-Wdynamic-class-memaccess] > > >>>> > > >>>> memcpy(this, func, sizeof(SampledFunction)); > > >>>> ~~~~~~ ^ > > >>>> > > >>>> Function.cc:422:10: note: explicitly cast the pointer to silence this > > >>>> warning > > >>>> > > >>>> At least categrory 5. sound serious to me, I would never have copied > > >>>> instances of C++ objects in that way, because it depends on the > > >>>> compiler > > >>>> and the class if this causes problems on runtime, s. i.e. > > >>>> http://weseetips.com/tag/afx_zero_init_object/, > > >>> > > >>> Note this is memset-ing to 0, not memcpy-ing a class to itself. To be > > >>> honest i agree memcpy'in a SampledFunction to a SampledFunction is > > >>> ugly, > > >>> but i fail to see why it would not work. > > > > It works, at least with the actual used compilers. But it works only, > > because the allocated members of SampledFunction are overwriten after > > doing the memcpy. And this behaviour makes it just more ugly in my eyes. > > And this is the same with the other memcpy's in ExponentialFunction, > > StitchingFunction and PostScriptFunction. And it will work till such > > time as everybody who changes the class will not forget to do it in the > > same way. So if You are not willing to change it (or let somebody else > > change it, I know, never change running code), we could use the hint: > > explicitly cast the pointer to silence this warning. > > I'm fine with someone fixing the code. Less warnings is always good, but for > master, there's no need to introduce a pontential breaker just because > clang complains.
So at the end noone volunteered to re-rewite those functions not to use memcpy over classes with virtuals? Cheers, Albert > > Cheers, > Albert > > > Cheers, > > Thomas > > > > >> Hi Albert, > > >> > > >> :-) > > >> > > >> A pointer of type SampleFunction* could be pointing to an instance of a > > >> SampleFunction sub-class, which has different vtable contents. > > > > > > No, it could not, SampledFunction does not have any childs and the > > > function > > > doing that memcopy is private anyway. > > > > > >> As a result, > > >> one could construct a SampleFunction with SampleFunction(SampleFunction > > >> *) > > >> using a pointer to a sub-class instance, and overwrite the > > >> SampleFunction's > > >> vtable address with the sub-class's vtable address. > > >> > > >> I am not sure if it will lead to any bugs/vulnerabilities in this case, > > >> but > > >> it is not safe practice in general. > > > > > > Sure, i never said it was. I'm just saying i don't see why it would not > > > work in our case. > > > > > >> Since the vtable structure depends on > > >> how the compiler is implemented, memcpy or memset on object pointers > > >> will > > >> generally lead to undefined behaviors. > > > > > > I'm far from a compiler expert, but one would hope that for a given > > > class > > > the compiler stores always the "stuff" in the same order in memory, so > > > again, i fail to see why this should fail in our case. > > > > > > Cheers, > > > > > > Albert > > >> > > >> Thanks. > > >> _______________________________________________ > > >> poppler mailing list > > >> [email protected] > > >> http://lists.freedesktop.org/mailman/listinfo/poppler > > > > > > _______________________________________________ > > > poppler mailing list > > > [email protected] > > > http://lists.freedesktop.org/mailman/listinfo/poppler > > > > > > . > > > > _______________________________________________ > > poppler mailing list > > [email protected] > > http://lists.freedesktop.org/mailman/listinfo/poppler > > _______________________________________________ > poppler mailing list > [email protected] > http://lists.freedesktop.org/mailman/listinfo/poppler _______________________________________________ poppler mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/poppler
