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

please reconsider fix for bug 557 #3165

Closed
vicuna opened this issue Jan 22, 2002 · 1 comment
Closed

please reconsider fix for bug 557 #3165

vicuna opened this issue Jan 22, 2002 · 1 comment
Labels

Comments

@vicuna
Copy link

vicuna commented Jan 22, 2002

Original bug ID: 825
Reporter: administrator
Status: closed
Resolution: not a bug
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: Doug Bagley
Version: 3.04
OS: Linux
Submission from: kof.bagley.org (216.30.46.7)

The fix for bug 557 means that another program cannot communicate information to
an ocaml program via argv[0] during an execv(), (even if the ocaml program is
built optimized).

My situation is that I have written a trampoline program to use for Ocaml
scripting instead of a custom toplevel (because custom toplevel can print
diagnostics to stdout, which is not good for scripts that act like filters).

My program is invoked via the interpreter line, does its magic to build the
script, if necessary, then invokes the built executable via execv(). Naturally
I want argv[0] to be the original script, but what I get, due to the fact that
Ocaml grabs that value from /proc, is the path to the cached executable, not the
script. I should be able to override argv[0] by passing the value I want in the
arg array to execv(), but the fix for 557 prevents this.

I would like to propose an alternate fix for 557: If bytecode programs need to
find themselves, then I believe that they can take argv[0], if it is absolute,
or prepend getcwd(), if it is relative. Alternatively, maybe the fix for 557
could only apply to bytecode programs, not programs built by ocamlopt.

Thanks,
Doug

@vicuna
Copy link
Author

vicuna commented Feb 11, 2002

Comment author: administrator

See #3159

@vicuna vicuna closed this as completed Feb 11, 2002
@vicuna vicuna added the bug label Mar 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant