: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

Activity

Show:
Alex Miller
April 6, 2015, 5:30 PM

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

Nicola Mometto
March 30, 2015, 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, 8:47 PM

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

Nicola Mometto
March 29, 2015, 8:38 PM

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

Completed
Your pinned fields
Click on the next to a field label to start pinning.

Assignee

Alex Miller

Reporter

Adrian Medina

Labels

Approval

Ok

Patch

Code and Test

Priority

Major

Affects versions

Fix versions