Mailing List Archive: MGVTBL fields access

In the struct mgvtbl there're three trailing fields - svt_copy,
svt_dup, svt_local - that were added to it in the 5.8 series. Some
modules on CPAN use their own custom definitions of MGVTBL, with only
5 out 8 members, leaving those three fields out. This works because of
all accesses to them in core are guarded with appropriate MGf_ flags.
Some others check for the presence of a MGf_ definitions or for the
BCD version and define their structs correctly with all required
fields.

Are those modules that assume that all accesses to those three fields
are guarded by the corresponding MGf_ flag right? Or there's no such
promise from the core, so they have a bug lurking?

Best regards,
Sergey Aleynikov

On Wed, Sep 20, 2023 at 01:32:59PM +0300, Sergey Aleynikov wrote:
> Are those modules that assume that all accesses to those three fields
> are guarded by the corresponding MGf_ flag right? Or there's no such
> promise from the core, so they have a bug lurking?

From perlguts:

The last three slots are a recent addition, and for source code
compatibility they are only checked for if one of the three flags
C<MGf_COPY>, C<MGf_DUP>, or C<MGf_LOCAL> is set in mg_flags.
This means that most code can continue declaring
a vtable as a 5-element value. These three are
currently used exclusively by the threading code, and are highly subject
to change.

So for example core won't access the svt_copy field unless the MGf_COPY
flag is set. Thus, older XS code which doesn't know to initialise the
svt_copy field to NULL will work ok on modern perls.

--
Art is anything that has a label (especially if the label is "untitled 1")