srfi-19 dumps core in response to bad arguments

[Tony Sidaway]

csi -R srfi-19
(format-date #t "~Y")
Segmentation fault

csi -R srfi-19
(format-date #t "~Y")
Segmentation fault

This typically dumps users back from the REPL to the shell command line, losing their session. If this is encountered in compiled code, the program bails without explanation.

An error should be raised saying that the date object must be specified.

Also:
csi -R srfi-19
(format-date #t "")
Error: (get-output-string) argument is not a string-output-port: #<output port "(stdout)">

An error should be raised saying that the date object must be specified or that the format string is empty.

csi -R srfi-19
(format-date #t "~Y" (make-date 0 2 1 13 10 11 2009 0))
Error: (get-output-string) argument is not a string-output-port: #<output port "(stdout)">

The same happens if an output port is given instead of #t

According to the online documentation for the SRFI-19 egg, this procedure call should write the formatted date to (current-output-port) or to the specified port.

[Tony Sidaway]

The documentation of format-date could be made more clear by specifying two alternative forms:

[procedure] (format-date DESTINATION DATE-FORMAT-STRING [DATE])
[procedure] (format-date DATE-FORMAT-STRING DATE)

Alternatively the requirement to specify a date in the latter case could be dropped, and the current date and time could be taken as the default value, as in the first alternative form.

Thus:

[procedure] (format-date DESTINATION DATE-FORMAT-STRING [DATE])
[procedure] (format-date DATE-FORMAT-STRING [DATE])

[Kon Lovett]

See release 3.0.2 for a more robust {{format-date}}.

[Tony Sidaway]

It's now robust, thanks, although the messages are a little cryptic:

(format-date #t "~Y")
Error: (format-date) bad argument type - not a date: #f

(format-date #t 12)

Same error message