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

Jump to bottom

Dynlink.allow_only should call default_available_units or docs should be updated #4771

Closed
vicuna opened this issue Apr 15, 2009 · 4 comments
Closed

Dynlink.allow_only should call default_available_units or docs should be updated #4771

vicuna opened this issue Apr 15, 2009 · 4 comments
Labels
bug
Milestone
4.02.0

Comments

@vicuna
Copy link

vicuna commented Apr 15, 2009

Original bug ID: 4771
Reporter: @dra27
Status: closed (set by @damiendoligez on 2014-07-31T15:27:08Z)
Resolution: fixed
Priority: normal
Severity: minor
Version: 3.11.0
Target version: 4.02.0+dev
Fixed in version: 4.02.0+dev
Category: ~DO NOT USE (was: OCaml general)
Monitored by: @glondu

Bug description

Dynlink.allow_only filters the current list of units available to dynlink'd modules. This is slightly counterintuitive for subsequent calls to allow_only (e.g. in the toplevel) where one might reasonably assume that:

Dynlink.allow_only ["Pervasives"];;
(* Dynlink.loadfile a file and get an exception about module String *)
Dynlink.allow_only ["Pervasives"; "String"];;

meant that Pervasives and String are now both available when in fact only Pervasives will be.

Either allow_only should call default_available_units before filtering or the documentation should be clearer as to how the function behaves.
@vicuna
Copy link
Author

vicuna commented Sep 17, 2012

Comment author: @damiendoligez

Fix the docs.

@vicuna
Copy link
Author

vicuna commented Jul 22, 2013

Comment author: @alainfrisch

It seems that the behavior is different in native code (allow_only calls init() first).

@vicuna
Copy link
Author

vicuna commented Jul 31, 2014

Comment author: @damiendoligez

I've tested it and the behavior is the same in native code.

@vicuna
Copy link
Author

vicuna commented Jul 31, 2014

Comment author: @damiendoligez

I have changed the documentation of allow_only to clarify this behavior (which is the intended behavior).
(fixed in 4.02, commit 15037)

@vicuna vicuna closed this as completed Jul 31, 2014
@vicuna vicuna added this to the 4.02.0 milestone Mar 14, 2019
@vicuna vicuna added the bug label Mar 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
4.02.0
Development

No branches or pull requests
1 participant
@vicuna