Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lround() is not exported from POSIX #15260

Closed
p5pRT opened this issue Apr 2, 2016 · 8 comments
Closed

lround() is not exported from POSIX #15260

p5pRT opened this issue Apr 2, 2016 · 8 comments

Comments

@p5pRT
Copy link

p5pRT commented Apr 2, 2016

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

Searchable as RT127821$

@p5pRT
Copy link
Author

p5pRT commented Apr 2, 2016

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
Copy link
Author

p5pRT commented Apr 2, 2016

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
Copy link
Author

p5pRT commented Apr 2, 2016

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

@p5pRT
Copy link
Author

p5pRT commented Apr 2, 2016

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
Copy link
Author

p5pRT commented Apr 2, 2016

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
Copy link
Author

p5pRT commented Apr 5, 2016

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
Copy link
Author

p5pRT commented May 16, 2016

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 p5pRT closed this as completed May 16, 2016
@p5pRT
Copy link
Author

p5pRT commented May 16, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant