Skip Menu |

Subject: Bleadperl v5.21.6-51-ge41e986 breaks BDB
Download (untitled) / with headers
text/plain 269b
Formerly the & prototype allowed ‘undef’ as an argument, contrary to the documentation. that changed in v5.21.6-51-ge41e986. The question is: Do we need to permit ‘undef’ and adjust the documentation? Or does BDB need to be fixed? -- Father Chrysostomos
Subject: Re: [perl #123475] Bleadperl v5.21.6-51-ge41e986 breaks BDB
From: Eric Brine <ikegami [...] adaelis.com>
To: perl5 porters <perl5-porters [...] perl.org>
Date: Sun, 21 Dec 2014 15:48:50 -0500
CC: "bugs-bitbucket [...] rt.perl.org" <bugs-bitbucket [...] rt.perl.org>
Download (untitled) / with headers
text/plain 909b


On Sun, Dec 21, 2014 at 2:33 PM, Father Chrysostomos <perlbug-followup@perl.org> wrote:
Show quoted text
# New Ticket Created by  Father Chrysostomos
# Please include the string:  [perl #123475]
# in the subject line of all future correspondence about this issue.
# <URL: https://rt.perl.org/Ticket/Display.html?id=123475 >


Formerly the & prototype allowed ‘undef’ as an argument, contrary to the documentation.  that changed in v5.21.6-51-ge41e986.

The question is:  Do we need to permit ‘undef’ and adjust the documentation?  Or does BDB need to be fixed?


It feels wrong to allow undef, but I don't have a good argument for or against.

The only thing I have is that permitting undef would be inconsistent
 
>perl -we"sub f(\@) { } f(@a); f(undef);"
Type of arg 1 to main::f must be array (not undef operator) at -e line 1, near "undef)"
Execution of -e aborted due to compilation errors.


RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 379b
On Sun Dec 21 11:33:02 2014, sprout wrote: Show quoted text
> Formerly the & prototype allowed ‘undef’ as an argument, contrary to > the documentation. that changed in v5.21.6-51-ge41e986. > > The question is: Do we need to permit ‘undef’ and adjust the > documentation? Or does BDB need to be fixed?
I think it's a bug fix, and if BDB depends on that bug it needs to be fixed. Tony
From: Andreas Koenig <andreas.koenig.7os6VVqR [...] franz.ak.mind.de>
Date: Tue, 24 Mar 2015 08:19:23 +0100
To: "Tony Cook via RT" <perlbug-followup [...] perl.org>
Subject: Re: [perl #123475] Bleadperl v5.21.6-51-ge41e986 breaks BDB
Download (untitled) / with headers
text/plain 128b
also affected ------------- JNQUINTIN/Math-Permute-Array-0.043.tar.gz (brought to my attention by Slaven Rezić) -- andreas
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 290b
On Tue Mar 24 00:20:05 2015, andreas.koenig.7os6VVqR@franz.ak.mind.de wrote: Show quoted text
> also affected > ------------- > JNQUINTIN/Math-Permute-Array-0.043.tar.gz > > (brought to my attention by Slaven Rezić)
Patch at <https://rt.cpan.org/Ticket/Display.html?id=103041>. -- Father Chrysostomos
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 166b
I can't easily compile BDB here. Is the fix as simple as changing the PROTOTYPE entry for set_sync_prepare in BDB.xs to ";&" ? Could someone verify this? -- rjbs
To: Ricardo SIGNES via RT <perlbug-followup [...] perl.org>
Date: Tue, 5 May 2015 16:33:21 +0100
Subject: Re: [perl #123475] Bleadperl v5.21.6-51-ge41e986 breaks BDB
CC: perl5-porters [...] perl.org
From: Dave Mitchell <davem [...] iabyn.com>
On Mon, Apr 27, 2015 at 03:15:34PM -0700, Ricardo SIGNES via RT wrote: Show quoted text
> I can't easily compile BDB here. Is the fix as simple as changing the > PROTOTYPE entry for set_sync_prepare in BDB.xs to ";&" ?
Not really. It would also have to change the XS implementation to handle a variable number of args, and still wouldn't handle the case of an explicit 'undef' arg. Looking at the usage in BDB, I think an undef value should still be allowed as an argument to a '&' parameter. BDB.pm does this as part of its initialisation: set_sync_prepare (undef); where set_sync_prepare() is used to register a callback. So in this case it is explicitly initialising its state to "no callback registered". I think this is a reasonable use of the & prototype. Looking at the original '&' ticket, #123062: & prototype is too permissive I think it's correct that it should dis-allow array refs etc, but I think undef should be re-allowed for 5.22. -- Dave's first rule of Opera: If something needs saying, say it: don't warble it.
CC: perl5-porters [...] perl.org
From: Dave Mitchell <davem [...] iabyn.com>
Subject: Re: [perl #123475] Bleadperl v5.21.6-51-ge41e986 breaks BDB
To: Ricardo SIGNES via RT <perlbug-followup [...] perl.org>
Date: Wed, 6 May 2015 12:03:27 +0100
Download (untitled) / with headers
text/plain 1.9k
On Tue, May 05, 2015 at 04:33:21PM +0100, Dave Mitchell wrote: Show quoted text
> On Mon, Apr 27, 2015 at 03:15:34PM -0700, Ricardo SIGNES via RT wrote:
> > I can't easily compile BDB here. Is the fix as simple as changing the > > PROTOTYPE entry for set_sync_prepare in BDB.xs to ";&" ?
> > Not really. It would also have to change the XS implementation to handle > a variable number of args, and still wouldn't handle the case of an > explicit 'undef' arg. > > Looking at the usage in BDB, I think an undef value should still be > allowed as an argument to a '&' parameter. > > BDB.pm does this as part of its initialisation: > > set_sync_prepare (undef); > > where set_sync_prepare() is used to register a callback. So in this case > it is explicitly initialising its state to "no callback registered". I > think this is a reasonable use of the & prototype. > > Looking at the original '&' ticket, > > #123062: & prototype is too permissive > > I think it's correct that it should dis-allow array refs etc, but I think > undef should be re-allowed for 5.22.
If no one objects, I'll merge the following commit once it's smoked: commit 343d03e768e8a0fd8d9aca836df191d819f4e3e8 Author: David Mitchell <davem@iabyn.com> AuthorDate: Wed May 6 11:56:47 2015 +0100 Commit: David Mitchell <davem@iabyn.com> CommitDate: Wed May 6 12:01:06 2015 +0100 allow undef as an arg to '&' prototype RT #123475 Commit e41e9865be5555 (to fix [perl #123062]) restricted the types of args allowed for a function with a '&' prototype - previously it allowed array refs and the like. It also removed undef, so this was now a compile-time error: sub foo (&) {...} foo(undef) However, some CPAN code used the idiom register_callback(undef) to explicitly disable a registered callback. So re-allow an explicit undef. -- print+qq&$}$"$/$s$,$a$d$g$s$@$.$q$,$:$.$q$^$,$@$a$~$;$.$q$m&if+map{m,^\d{0\,},,${$::{$'}}=chr($"+=$&||1)}q&10m22,42}6:17a2~2.3@3;^2dg3q/s"&=~m*\d\*.*g
Subject: Re: [perl #123475] Bleadperl v5.21.6-51-ge41e986 breaks BDB
CC: Ricardo SIGNES via RT <perlbug-followup [...] perl.org>, perl5-porters [...] perl.org
From: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
To: Dave Mitchell <davem [...] iabyn.com>
Date: Wed, 6 May 2015 09:26:47 -0400
Download (untitled) / with headers
text/plain 1.9k
* Dave Mitchell <davem@iabyn.com> [2015-05-05T11:33:21] Show quoted text
> I think it's correct that it should dis-allow array refs etc, but I think > undef should be re-allowed for 5.22.
I wrote many, many long responses to this, each one different than the previous, as I reached logical dead ends. The behavior and intent of prototypes is, in my opinion, so incoherent as to make any reasoning from first principles unlikely to bear fruit. So, instead, I think we have a really simple choice. Here's what the docs say about (&): An "&" requires an anonymous subroutine, which, if passed as the first argument, does not require the "sub" keyword or a subsequent comma. The old behavior allows: sub takes_sub (&) { ... } takes_sub(undef); ...which contradicts the documentation. We should change the behavior or we should change the documentation. Changing the documentation and leaving the code alone (relative to v5.20) will let things like BDB continue to work, where a literal undef is passed to reset a stored subroutine. Changing the code and leaving the documentation alone (again, relative to v5.20) will break anything that had relied on this behavior, but will expose bugs where a literal undef had been passed to a subroutine with a (&) prototype in effect. It will now issue a compile-time error. Presumably, these situations are bugs iff later something attempts $arg->(), which would currently be a runtime error. That doesn't mean that this wouldn't expose existing bugs, but I think it does cut down on what we'd expect to see fixed. Also, we should consider the prevention of future bugs, which won't ever need to be detected at runtime. Nonetheless, it is with heavy heart that I think I agree with the suggested course of action: go back to the old, worse behavior. If we were starting from scratch, I would hold my ground, but I don't think the breakage is justified here. Boy, do I ever dislike prototypes! If anybody wants to change my mind, do so quickly! ;) Or wait to try again in 5.23, I suppose... -- rjbs
Download signature.asc
application/pgp-signature 473b

Message body not shown because it is not plain text.

From: Dave Mitchell <davem [...] iabyn.com>
CC: Ricardo SIGNES via RT <perlbug-followup [...] perl.org>, perl5-porters [...] perl.org
Subject: Re: [perl #123475] Bleadperl v5.21.6-51-ge41e986 breaks BDB
Date: Fri, 8 May 2015 15:37:22 +0100
To: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
On Wed, May 06, 2015 at 09:26:47AM -0400, Ricardo Signes wrote: Show quoted text
> I wrote many, many long responses to this, each one different than the > previous, as I reached logical dead ends. The behavior and intent of > prototypes is, in my opinion, so incoherent as to make any reasoning from first > principles unlikely to bear fruit. > > So, instead, I think we have a really simple choice. Here's what the docs say > about (&): > > An "&" requires an anonymous subroutine, which, if passed as the first > argument, does not require the "sub" keyword or a subsequent comma. > > The old behavior allows: > > sub takes_sub (&) { ... } > takes_sub(undef); > > ...which contradicts the documentation. We should change the behavior or we > should change the documentation. > > Changing the documentation and leaving the code alone (relative to v5.20) will > let things like BDB continue to work, where a literal undef is passed to reset > a stored subroutine. > > Changing the code and leaving the documentation alone (again, relative to > v5.20) will break anything that had relied on this behavior, but will expose > bugs where a literal undef had been passed to a subroutine with a (&) > prototype in effect. It will now issue a compile-time error. Presumably, > these situations are bugs iff later something attempts $arg->(), which would > currently be a runtime error. That doesn't mean that this wouldn't expose > existing bugs, but I think it does cut down on what we'd expect to see fixed. > Also, we should consider the prevention of future bugs, which won't ever need > to be detected at runtime. > > Nonetheless, it is with heavy heart that I think I agree with the suggested > course of action: go back to the old, worse behavior. If we were starting > from scratch, I would hold my ground, but I don't think the breakage is > justified here.
Now merged with v5.21.11-77-g8283f70 -- The warp engines start playing up a bit, but seem to sort themselves out after a while without any intervention from boy genius Wesley Crusher. -- Things That Never Happen in "Star Trek" #17
Subject: Your ticket against Perl 5 has been resolved
Download (untitled) / with headers
text/plain 263b
Thanks for submitting this ticket The issue should be resolved with the release today of Perl v5.22, available at http://www.perl.org/get.html If you find that the problem persists, feel free to reopen this ticket -- Karl Williamson for the Perl 5 porters team


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org