Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#1184 closed defect (notabug)

(read-from-string "#-genera" nil nil) should return nil, gets exception instead

Reported by: lispwizard Owned by:
Priority: normal Milestone:
Component: ANSI CL Compliance Version: 1.9
Keywords: Cc:

Description

I can understand why this happens, but if I supply an eof-error-p argument of nil and an eof-value of nil, I should just get nil, no? (At least that's how I interpret the hyperspec entry for read-from-string.)

(I'm doing some processing of files line-by-line, and this line happened to come all by itself ahead of the definition of a function on the next few lines.)

I tried this both in a shipped 1.9 and in a second 1.9 which had been updated via svn update and fully rebuilt.

Change History (3)

comment:1 Changed 6 years ago by gb

  • Resolution set to notabug
  • Status changed from new to closed

I don't know of anything in the spec that says anything about whether your expectation or CCL's behavior is correct. Implementations differ.

If you can find a convincing argument in favor of your expectations, I'd be interested in hearing it, If you're just depending on undefined behavior, this is an example of why you shouldn't do that.

comment:2 Changed 6 years ago by lispwizard

The hyperspec says:

If the end of the supplied substring occurs before an object can be read, an error is signaled if eof-error-p is true. An error is signaled if the end of the substring occurs in the middle of an incomplete object.

Which seems to imply that this doesn't happen if eof-error-p is not true and we hit EOF before an object can be read. We are not "in the middle of an incomplete object", as, say in the middle of a list with no closing parenthesis.

comment:3 Changed 6 years ago by gb

The package that you quote explains why

(read-from-string "")

and

(read-from-string "" nil nil)

differ. That isn't relevant.

The #+ and #- reader macros cause READ to be called a couple of times (to read the feature expression and the following expression.) These inner calls to READ may be surrounded by bindings of *PACKAGE* and *READ-SUPPRESS*, and that's well-specified. How EOF is handled in these inner calls to READ isn't specified at all, and implementations differ, and this is relevant.

If you can find something in the spec that describes how the relevant issue should be handled, that would be useful. Quoting irrelevant passages in the spec isn't useful, so please stop doing that.

Note: See TracTickets for help on using tickets.