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

Reply via email to