:eof option in clojure.core/read not handled properly

Description

Example form which exhibits the behavior:

(read {:read-cond :allow :eof (Object.)} input)

When EOF is reached in the stream, instead of returning the :eof value specified the boolean value true is always returned instead. If you omit :eof from the option map given to clojure.core/read, false is consistently returned and no EOF error is thrown.
Patch: 0001-CLJ-1685-correctly-handle-eof-option-in-read-read-st-v2.patch

Note: Currently

behaves like

rather than

, the proposed patch makes it believe like

, the proposed patch changes this so that the default behaviour is always to throw on eof unless a :eof option is explicitly included in the read opts.

Patch: clj-1685-v3.patch

Screened by: Alex Miller

Environment

None

Attachments

3

Activity

Show:

Alex Miller April 6, 2015 at 5:30 PM

The -v3 patch is identical to -v2, but adds one clarifying docstring addition.

Nicola Mometto March 30, 2015 at 2:20 PM

Alex, currently calls to read/read-string with an empty options map behave as if {:eof nil} was passed, thus

i.e, :eof defaults to nil.
Is this intended? if not, the attached patch 0001-CLJ-1685-correctly-handle-eof-option-in-read-read-st-v2.patch
fixes this issue and changes the behaviour of read/read-string to default to :eofthrow rather than to nil

Andy Fingerhut March 29, 2015 at 8:47 PM

Never try to race Nicola to a patch when he is on the task Thanks, Nicola.

Nicola Mometto March 29, 2015 at 8:38 PM

Attached patch fixes the issue for both read and read-string

Completed

Details

Assignee

Reporter

Labels

Approval

Ok

Patch

Code and Test

Priority

Affects versions

Fix versions

Created March 29, 2015 at 7:26 PM
Updated April 10, 2015 at 4:58 PM
Resolved April 10, 2015 at 4:58 PM