Front page | perl.perl5.porters |
Postings from May 2016
On 05/23/2016 09:01 AM, Dave Mitchell wrote: > On Wed, May 18, 2016 at 08:46:48PM +0100, Nicholas Clark wrote: >> It's as much source compatibility. > > Ah I see. > > I've added the following text to mathoms.c which hopefully describes the > current situation: > > commit d7244c9a613101b97077ed781e11a729c347555c > Author: David Mitchell <davem@iabyn.com> > AuthorDate: Mon May 23 15:45:20 2016 +0100 > Commit: David Mitchell <davem@iabyn.com> > CommitDate: Mon May 23 15:45:20 2016 +0100 > > mathoms.c: add explanation why fns must be kept > > See http://nntp.perl.org/group/perl.perl5.porters/236384. > > > Affected files ... > M mathoms.c > > Differences ... > > diff --git a/mathoms.c b/mathoms.c > index 6c60328..0ebf434 100644 > --- a/mathoms.c > +++ b/mathoms.c > @@ -21,8 +21,16 @@ > > /* > * This file contains mathoms, various binary artifacts from previous > - * versions of Perl. For binary or source compatibility reasons, though, > - * we cannot completely remove them from the core code. > + * versions of Perl which we cannot completely remove from the core > + * code. There are two reasons functions should be here: > + * > + * 1) A function has been been replaced by a macro within a minor release, > + * so XS modules compiled against an older release will expect to > + * still be able to link against the function > + * 2) A function Perl_foo(...) with #define foo Perl_foo(aTHX_ ...) > + * has been replaced by a macro, e.g. #define foo(...) foo_flags(...,0) > + * but XS code may still explicitly use the long form, i.e. > + * Perl_foo(aTHX_ ...) > * > * REMEMBER to update makedef.pl when adding a function to mathoms.c whose > * name doesn't begin with "Perl_". > > That diff showed me that the REMEMBER caution is obsolete, as a result of my recent fixes. So, I have pushed a patch to remove it. But while we are on this topic, when can we remove things from mathoms? There are a bunch of functions currently in it that have been deprecated for some time. This deprecation is done simply by adding a 'D' flag to their entries in embed.fnc, which causes gcc to mark them as deprecated, but only if you bother reading over the compilation output. I don't know what other compilers, if any, do anything special with this. Is there a rule we can devise about when we can remove such functions?Thread Previous | Thread Next