I've made a branch for the final PDL-2.007 edits. Please feel free to continue development on the problem as desired.
Cheers, Chris On Fri, Oct 11, 2013 at 6:57 PM, Chris Marshall <[email protected]> wrote: > 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
