#5481 hue, saturation and value palettes are not checked; a bad one gives a Lisp error when plotting

[David Scherfgen]

This bug was discovered by Claude Opus 5.5 and reproduced on Maxima Git commit c62924c (2026-09-26) with SBCL 2.2.9.

Where: src/plot.lisp, CHECK-OPTION-PALETTE

CHECK-OPTION-PALETTE checks a hard-coded list #$[value,0.2,0,0,10]$ instead of the palette given. So the documented rule that the first three numbers lie in [0,1], followed by a fourth number, is never enforced, and [value,0.2] later makes GNUPLOT-PALETTE add NIL to a number.

Steps

1. Verify that the existing behavior is incorrect: run the reproducer below; it gives the result under "Before the fix". Judge for yourself that this is wrong instead of relying on the ticket: where the bug allows it, try some related inputs of your own, or check the result another way, for example numerically or against the documentation. A Lisp error is wrong in itself.
2. Edit the file src/plot.lisp as described under "Fix".
3. Rebuild Maxima.
4. Verify that the behavior is now correct: the reproducer gives the result under "Correct result". Judge for yourself that this is right, not only that it matches: where the bug allows it, try some related inputs of your own, including some that the fix should leave unchanged.
5. Add the test case(s) under "Test cases" to tests/rtest_plotoptions.mac, at the end of the file.
6. Run the complete test suite, share tests included (make check, or run_testsuite(share_tests=true); in ./maxima-local), and check that the change breaks no test. Failures that also occur without the change (a run on the unchanged build shows which) are pre-existing and can be ignored.
7. Add the line * \#5481 hue, saturation and value palettes are not checked; a bad one gives a Lisp error when plotting to ChangeLog, under "Bug fixes for numbered bugs:".
8. Commit the fix; a proposed Git commit message is under "Commit message".
9. Push the commit. Then set this ticket's status to "closed" and add a comment naming the commit, for example Fixed by commit [1a2b3c]., with the first six characters of the commit's SHA in the brackets (git rev-parse HEAD | cut -c1-6 prints them). SourceForge links this to the commit.

Reproducer

set_plot_option([palette,[hue,7,-3,12,10]]); plot3d(x*y,[x,0,1],[y,0,1],[palette,[value,0.2]],[plot_format,gnuplot],[run_viewer,false],[gnuplot_script_file,"/tmp/b28.gp"]);

Before the fix:

the first palette is accepted; the plot3d call gives: Maxima encountered a Lisp error: The value NIL is not of type NUMBER

Correct result:

Maxima errors from the option check (Expecting a number between 0 and 1 found 7.0; Wrong number of arguments for plot option value)

Fix

In src/plot.lisp (CHECK-OPTION-PALETTE, line "(check-option (butlast (cdr #$[value,0.2,0,0,10]$))"), replace

                 (check-option (butlast (cdr #$[value,0.2,0,0,10]$))

with

                 (check-option (butlast (cdr palette))

Test cases

Add these lines to tests/rtest_plotoptions.mac, separated from the tests before them by two empty lines:

/* Bug #5481: "hue, saturation and value palettes are not checked; a bad one gives a Lisp error when plotting" */

block ([r],
  reset_plot_options (),
  r: [errcatch (set_plot_option ([palette, [hue, 7, -3, 12, 10]])),
      errcatch (set_plot_option ([palette, [value, 0.2]])),
      (set_plot_option ([palette, [hue, 0.25, 0.7, 0.8, 0.5]]),
       get_plot_option (palette))],
  set_plot_option ([palette, default]),
  reset_plot_options (),
  r);
[[], [], [palette, hue, 0.25, 0.7, 0.8, 0.5]]$

Commit message

plot.lisp: check hue, saturation and value palettes

CHECK-OPTION-PALETTE checked the constant list [value, 0.2, 0, 0, 10]
instead of the palette given, so a hue, saturation or value palette with
numbers outside [0, 1] or with too few numbers was accepted and later
caused a Lisp error when plotting. Check the palette given.

This fixes bug #5481.

Found and fixed by Claude Opus 5.5.