Is it safe to store a pointer to a C struct in an SV?
I'm trying to write a source code filter and I have a need for the SV
that Perl makes available via FILTER_DATA() to carry some baggage around
with it (in the shape of a pointer to a struct). Basically the setup
looks like this:
static I32 my_filter(pTHX_ int idx, SV *buf_sv, int maxlen) {
SV *sv = FILTER_DATA(idx);
...
}
where my_filter has previously been installed with a call like:
filter_add(my_filter, sv);
The SV that I create and pass to filter_add() is the one that is made
available later in my_filter() by FILTER_DATA().
The problem is that my_filter() requires a struct to be made avilable to
it. The only way that I can think of to do this (other than using, say,
a file scope static variable) is to store the struct pointer in the SV,
something like this before the filter_add() call:
MY_STRUCT my_struct;
sv = newSVuv((unsigned long) &my_struct);
SvIOK_only_UV(sv);
and later on my_filter() can then access:
(MY_STRUCT *) SvUVX(sv)
However, the struct now available within my_filter() doesn't seem to be
working properly...
If I switch to using a file scope static variable for the struct then it
works OK for one filtered source file, but this approach is not feasible
in general because if one filtered source file loads another one then
the second filter starts writing all over the struct that was being used
by the first filter! They need to have their "own" structs available,
hence I wanted to store a pointer to it on the SV.
Is that a "safe" thing to do in general? Any ideas what might be going
wrong here?
Thanks,
- Steve
------------------------------------------------
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are
confidential and intended for the addressee(s) only. If you have received this
message in error or there are any problems, please notify the sender immediately. The
unauthorized use, disclosure, copying or alteration of this message is strictly
forbidden. Note that any views or opinions presented in this email are solely those
of the author and do not necessarily represent those of Radan Computational Ltd. The
recipient(s) of this message should check it and any attached files for viruses: Radan
Computational will accept no liability for any damage caused by any virus transmitted
by this email.
