:save-runtime-options does not inhibit CLI processing in saved Lisp executable

Bug #2096995 reported by Zach Beane
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
SBCL
New
Undecided
Unassigned

Bug Description

sbcl --dynamic-space-size 1000 --no-userinit --no-sysinit \
  --eval '(sb-ext:save-lisp-and-die #P"x" :executable t :save-runtime-options t :toplevel (lambda () (format t "~&~S~%" sb-ext:*posix-argv*)))'

$ ./x hello
("./x" "hello")

$ ./x --dynamic-space-size 3000 hello
("./x" "hello")

The point of save-runtime-options is to inhibit the consumption of --dynamic-space-size in user executables. It doesn't look like it's working properly. I would expect "--dynamic-space-size" "3000" to be in the output.

I'm using SBCL 2.5.0.

Revision history for this message
Stas Boukarev (stassats) wrote :

That's on purpose.

Revision history for this message
Zach Beane (xach) wrote :

The intent when I added :save-runtime-options was the opposite, and my interpretation is also how it's documented in the manual and docstrings of the involved functions.

If it continues to work this way, there's no way a user executable can opt out of SBCL C runtime options, which seems like bad behavior to me.

Revision history for this message
Zach Beane (xach) wrote :

Also, SBCL 2.1.0 works as expected and documented. I'll try bisecting to see where things changed.

Revision history for this message
Stas Boukarev (stassats) wrote :

git blame is faster: f0a7f17516fb4ddd784233cef17896a13d5d6e15

Revision history for this message
Zach Beane (xach) wrote :

Thanks for the info. This change breaks buildapp (nobody noticed until recently) which accepts a --dynamic-space-size argument set the size of the resulting dumped executable.

I don't think this is a highly dubious scenario (to use the wording of the commit). Can this change be reverted?

Revision history for this message
Douglas Katzman (dougk) wrote :

Without the aforementioned, there is no way to provide a default heap size that is also allowed to be user-specified. I don't know what buildapp is but I guess it conflicts with the use-case of "--dynamic-space-size" being an application-level option. Don't do that.

Revision history for this message
Zach Beane (xach) wrote :

Hi Doug, my view is that it's very useful for an application created with save-lisp-and-die to get all the command-line arguments with no interception whatsoever from the SBCL runtime. Not every application created with SLAD is a SBCL development environment that should honor SBCL flags. When I added :save-runtime-options in 2008, it was with this capability in mind.

I agree that it's *also* really useful to specify the dynamic space size somehow -- maybe there's some other way to do it? Like with the environment?

If there's no way you can be persuaded to revert, I'll look into patching the docs to reflect the new behavior.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.