Trying to parse an empty string signals an implementation-internal TYPE-ERROR

[phoe]

CL-USER> (jzon:parse "")

The value
  0
is not of type
  (INTEGER 1)
from the function type declaration.
   [Condition of type TYPE-ERROR]

Restarts:
 0: [RETRY] Retry SLIME REPL evaluation request.
 1: [*ABORT] Return to SLIME's top level.
 2: [ABORT] Exit debugger, returning to top level.

Backtrace:
  0: ((LAMBDA NIL :IN JZON::%MAKE-FNS-SIMPLE-STRING))
  1: (JZON::%PARSE #<FUNCTION (LAMBDA NIL :IN JZON::%MAKE-FNS-SIMPLE-STRING) {120489076B}> #<FUNCTION (LAMBDA NIL :IN JZON::%MAKE-FNS-SIMPLE-STRING) {1204890C2B}> #<FUNCTION (LAMBDA NIL :IN JZON::%MAKE-FNS..
  2: (SB-INT:SIMPLE-EVAL-IN-LEXENV (JZON:PARSE "") #<NULL-LEXENV>)
  3: (EVAL (JZON:PARSE ""))
 --more--

Should probably be a JSON-ERROR of some sort.

[vindarel]

Duplicate and should be fixed since last September? #81

[phoe]

Still in Quicklisp's most recent dist though, due to a lack of release. https://github.com/quicklisp/quicklisp-projects/blob/2e314d2b48f6e65a5afc1fb399a1aec2466b8531/projects/jzon/source.txt

[phoe]

@vindarel Actually, no, not a duplicate.

CL-JSCHEMA> (asdf:system-source-directory :com.inuoe.jzon)
#P"/home/mhr/Projects/Lisp/jzon/"

CL-JSCHEMA> (legit:with-chdir (*)
              (legit:git-log :revision-range "HEAD^..HEAD"))
commit d5feb465244ac94630e8155f5bfbb45fc1d87b53
Merge: 40e5eeb 703cb7e
Author: Wilfredo Velázquez-Rodríguez <zulu.inuoe@gmail.com>
Date:   Wed Nov 12 16:31:16 2025 -0500

    Merge pull request #84 from fosskers/colin/fix-on-ecl
    
    fix: compilation under ECL

commit 703cb7ef502bb318715c5305e02664cee04ba9aa
Author: Colin Woodbury <colin@fosskers.ca>
Date:   Thu Nov 13 06:01:17 2025 +0900

    fix: compilation under ECL
T

CL-JSCHEMA> (com.inuoe.jzon:parse "")
; Evaluation aborted on #<TYPE-ERROR expected-type: (INTEGER 1) datum: 0>.

[phoe]

Here's a backtrace without inlining:

Backtrace:
  0: ((LAMBDA NIL :IN JZON::%MAKE-FNS-SIMPLE-STRING))
  1: (JZON::%RAISE JZON:JSON-EOF-ERROR #<FUNCTION (LAMBDA NIL :IN JZON::%MAKE-FNS-SIMPLE-STRING) {120E3A08BB}> "End of input when reading JSON element")
  2: (JZON::%PARSE-NEXT #S(JZON::%PARSER-STATE :%PARSER-STATE-STATE JZON::TOPLEVEL :%PARSER-STATE-LOOKAHEAD NIL :%PARSER-STATE-CONTEXT NIL) #<FUNCTION (LAMBDA NIL :IN JZON::%MAKE-FNS-SIMPLE-STRING) {120E3A..
  3: (JZON::%PARSE #<FUNCTION (LAMBDA NIL :IN JZON::%MAKE-FNS-SIMPLE-STRING) {120E3A088B}> #<FUNCTION (LAMBDA NIL :IN JZON::%MAKE-FNS-SIMPLE-STRING) {120E3A0D4B}> #<FUNCTION (LAMBDA NIL :IN JZON::%MAKE-FNS..
  4: (JZON:PARSE "" :MAX-DEPTH 128 :ALLOW-COMMENTS NIL :ALLOW-TRAILING-COMMA NIL :ALLOW-MULTIPLE-CONTENT NIL :MAX-STRING-LENGTH 1048576 :KEY-FN T)
  5: (SB-INT:SIMPLE-EVAL-IN-LEXENV (JZON:PARSE "") #<NULL-LEXENV>)
  6: (EVAL (JZON:PARSE ""))

So it actually detects an end of input and correctly tries to raise JSON-EOF-ERROR, but that takes a position function which needs to return a line and column or (VALUES NIL NIL). The functions created by (COM.INUOE.JZON::%MAKE-FNS-SIMPLE-STRING "" 0 0 1048576) don't seem to expect an empty string, and therefore attempts to pass 0 to %CALC-POS trigger a type assertion.

JZON code is complex, so I don't know if #92 is the best place to fix this. But a fix it is.