Skip Menu |
Report information
Id: 127821
Status: resolved
Priority: 0/
Queue: perl5

Owner: arc <arc [at] cpan.org>
Requestors: arc <arc [at] cpan.org>
Cc:
AdminCc:

Operating System: (no value)
PatchStatus: (no value)
Severity: low
Type: unknown
Perl Version: (no value)
Fixed In: (no value)



Subject: lround() is not exported from POSIX
Download (untitled) / with headers
text/plain 406b
POSIX.pm implements lround(), but doesn't export it. It's too late in the freeze for this to be fixed for 5.24, so it should be added to @EXPORT and to the relevant export tag early in the 5.25 cycle. In the mean time, commit 25a9f0e724ff0f469866f8713f0e79f3159bf870 adds it to @EXPORT_OK, so callers who want to use it can at least import it by explicit name. -- Aaron Crane ** http://aaroncrane.co.uk/
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 815b
On Sat Apr 02 04:01:46 2016, arc wrote: Show quoted text
> POSIX.pm implements lround(), but doesn't export it. It's too late in > the freeze for this to be fixed for 5.24, so it should be added to > @EXPORT and to the relevant export tag early in the 5.25 cycle. In the > mean time, commit 25a9f0e724ff0f469866f8713f0e79f3159bf870 adds it to > @EXPORT_OK, so callers who want to use it can at least import it by > explicit name.
Reading this makes me wonder: Are there other functions besides lround() implemented in the POSIX module but not exported? Do we have any sort of policy to determine which should be in @EXPORT and which should only be in @EXPORT_OK? (ISTR discussions in the past which complained that POSIX.pm automatically exported too many functions.) Thank you very much. -- James E Keenan (jkeenan@cpan.org)
CC: perl5-porters [...] perl.org
From: Glenn Golden <gdg [...] zplane.com>
To: James E Keenan via RT <perlbug-followup [...] perl.org>
Date: Sat, 2 Apr 2016 05:52:13 -0600
Subject: Re: [perl #127821] lround() is not exported from POSIX
Download (untitled) / with headers
text/plain 1.4k
James E Keenan via RT <perlbug-followup@perl.org> [2016-04-02 04:29:24 -0700]: Show quoted text
> On Sat Apr 02 04:01:46 2016, arc wrote:
> > POSIX.pm implements lround(), but doesn't export it. It's too late in > > the freeze for this to be fixed for 5.24, so it should be added to > > @EXPORT and to the relevant export tag early in the 5.25 cycle. In the > > mean time, commit 25a9f0e724ff0f469866f8713f0e79f3159bf870 adds it to > > @EXPORT_OK, so callers who want to use it can at least import it by > > explicit name.
> > Reading this makes me wonder: > > Are there other functions besides lround() implemented in the POSIX module > but not exported? > > Do we have any sort of policy to determine which should be in @EXPORT and > which should only be in @EXPORT_OK? > > (ISTR discussions in the past which complained that POSIX.pm automatically > exported too many functions.) >
Fwiw: Around a year ago, I was doing some work that required importing many POSIX functions, and seem to recall coming across this lround() exception that you mention above. I also have the vague recollection that I made some informal notes on other POSIX.pm functions that seemed to have been inconsistently exported, as they were discovered, with the intent of eventually reporting them here. Unfortunately, I can't put my hands on that list at the moment, but if you can bear with me for a week or so, will see if I can find it. Ping me on it if I forget.
Subject: Re: [perl #127821] lround() is not exported from POSIX
Date: Sat, 2 Apr 2016 13:53:42 +0100
To: perl5-porters [...] perl.org
From: Zefram <zefram [...] fysh.org>
Download (untitled) / with headers
text/plain 646b
James E Keenan via RT wrote: Show quoted text
>Do we have any sort of policy to determine which should be in @EXPORT >and which should only be in @EXPORT_OK?
We seem to be de facto following a policy that @EXPORT is frozen for all time, to avoid breaking existing users, so all new exportables go in @EXPORT_OK. I think this is the right policy. Show quoted text
>(ISTR discussions in the past which complained that POSIX.pm >automatically exported too many functions.)
Yeah. I'm no fan of @EXPORT in any case, but POSIX.pm particularly has a huge list of default exports, so a user can't possibly have all the exported names in mind when using the default export. -zefram
Subject: Re: [perl #127821] lround() is not exported from POSIX
From: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
To: perl5-porters [...] perl.org
Date: Tue, 5 Apr 2016 05:53:37 +0200
Download (untitled) / with headers
text/plain 1.4k
* Zefram <zefram@fysh.org> [2016-04-02 16:23]: Show quoted text
> James E Keenan via RT wrote:
> > Do we have any sort of policy to determine which should be in > > @EXPORT and which should only be in @EXPORT_OK?
> > We seem to be de facto following a policy that @EXPORT is frozen for > all time, to avoid breaking existing users, so all new exportables go > in @EXPORT_OK. I think this is the right policy.
I added the infrastructure to have @EXPORT differ from @EXPORT_OK due to complaints about some of the new exports Jarkko added during his work on Perl’s Inf/NaN support. I also brought up the of policy question at that time, and then recorded the consensus in a comment in ext/POSIX/t/export.t: # adding new functions to EXPORT is a BACKWARD COMPATIBILITY BREAKING CHANGE # it is OK to add new constants, but new functions may only go in EXPORT_OK … on the grounds that a new PFX_SHOUTYCONSTANT is extremely unlikely to clash with anyone’s existing subs. (Not all constants are prefixed, but almost.) I’m not sure any more that this is a sufficiently prominent place for that information. I had to go looking for it myself. It made sense to me at the time on the grounds that anyone changing the exports will have to edit that file, and they should be led to the comment by the fact that the list of symbols is broken into sections by perl version. But maybe that is too obscure. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 400b
lround() is in the :math_h_c99 export tag as of decf70bc4310d8f5fde9eaa759146c3548ab340a. Three subsequent commits ensure that several other missing symbols are exported. Finally, a26223c9fe9f719139f4223d916e9ed21e354873 adds a test to ensure that every symbol in the %POSIX:: stash that isn't part of the POSIX.pm implementation is exported in some way. -- Aaron Crane ** http://aaroncrane.co.uk/


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