On second thought, I'm going ahead with PDL-2.007 this evening as planned with the current issue in Known_problems. Once a fix is found, we can push a CPAN developers release that can be used by folks needing the fix immediately. It come in the next official release.
Sorry for any confusion, Chris On Fri, Oct 11, 2013 at 6:40 PM, Craig DeForest <[email protected]> wrote: > > On Oct 11, 2013, at 3:27 PM, Dima Kogan <[email protected]> wrote: >> Craig DeForest <[email protected]> writes: >>> But the code isn't really unsafe under less vigorous optimizing >>> compilers -- the problem is that whoever wrote that (Tuomas?) used a >>> massive autogenerated collection of similar-but-slightly-different >>> structs to simulate dynamically allocated arrays, with a superclass >>> generic struct that is used to access most of them. The memory is >>> out-of-bounds for the type to which the struct is cast (the generic >>> pdl_trans), but the bounds are maintained with runtime variables. >> >> Wait... what? I don't quite understand. The code here is fairly >> unambiguous. We have a >> >> struct pdl_trans >> >> object and we're trying to access data that's out of bounds. What we >> tell the compiler it's very clear, unless I'm missing something. Are you >> saying that the >> >> struct pdl_trans* >> >> we have here isn't actually pointing to a pdl_trans, but rather to >> something different that sorta looks like a pdl_trans, but has more >> elements? > > > Yes, that is exactly right. There are pdl_trans_<foo> objects all over the > place, autogenerated by PP.pm. They all use that PDL_TRANS_START macro to > ensure they have the same overall data structure but different static > autoallocated pdls arrays. They are cast to (pdl_trans *) before some of the > general purpose manipulations. > >> If so, we should be using the correct type so that we don't >> purposely lie to our compiler. >> >> I'm looking to see where the pdl_trans objects are getting allocated to >> get to the bottom of this. Do you know of the top of your head where >> this is done? > > using the correct type involves defining a single static type that can handle > all the transes. The original author (I think Tuomas) used the current > kludge to avoid having the runtime overhead of a dynamic array object, at the > expense of giving the compiler a workout. > > > > _______________________________________________ > Perldl mailing list > [email protected] > http://mailman.jach.hawaii.edu/mailman/listinfo/perldl _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
