lround() is not exported from POSIX

[p5pRT]

Migrated from rt.perl.org#127821 (status was 'resolved')

Searchable as RT127821$

[p5pRT]

From @arc

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 25a9f0e 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/

[p5pRT]

From @jkeenan

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 25a9f0e 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)

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From gdg@zplane.com

James E Keenan via RT <perlbug-followup@​perl.org> [2016-04-02 04​:29​:24 -0700]​:

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 25a9f0e 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.

[p5pRT]

From zefram@fysh.org

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.

(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

[p5pRT]

From @ap

* Zefram <zefram@​fysh.org> [2016-04-02 16​:23]​:

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/>

[p5pRT]

From @arc

lround() is in the :math_h_c99 export tag as of decf70b. Three subsequent commits ensure that several other missing symbols are exported. Finally, a26223c 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/

[p5pRT]

@arc - Status changed from 'open' to 'resolved'