That is the motivation for NO_INIT but the docs suggest that its operation is to stop any input stack handling code from being generated. I.e., xsubpp please don't touch, we'll do it ourselves... This particular usage may be a no-op but I don't think that breaks anything (unless memory is lost or the stack pointer is not correctly adjusted).
Cheers, Chris On Wed, Aug 17, 2011 at 9:38 AM, Sisyphus <[email protected]> wrote: > > ----- Original Message ----- From: "Chris Marshall" <[email protected]> > To: "Sisyphus" <[email protected]> > Cc: "[email protected]" <[email protected]> > Sent: Wednesday, August 17, 2011 11:16 PM > Subject: Re: [Perldl] PDL_Long typemap bug in 2/3 of PDL-2.4.9_004 > testreports > > >> Looking at the perlxs page I don't see any problem with >> the use of NO_INIT > > Except that, by my understanding of that documentation, NO_INIT is supposed > to signify that these variables are "output" variables. > But they're just variables that are going to be assigned a value, and I > doubt that makes them "output" variables. > > Of course, I'm not entirely sure what constitutes an "output" variable. From > the example it looks to me that "output" refers to the value that's going to > be returned - yet these variables contain values that are certainly not > being returned. > >> although I did notice that a bunch of >> the cases seemed to have a function parameter 'position' >> which was not used anywhere within the code. > > Yeah, I noticed unused params in some of those functions, too. It's all > rather weird. > >> It was >> also unclear where/how some of these routines like >> at_c are called.... > > Heh, wouldn't it be funny if they weren't being called at all. (Probly a > silly thing to say. I haven't looked at that aspect at all.) > > Cheers, > Rob > > > _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
