bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#679: 23.0.60; Function json-read-number does not handle complete Jav


From: Kevin Rodgers
Subject: bug#679: 23.0.60; Function json-read-number does not handle complete Javascript spec
Date: Tue, 12 Aug 2008 21:11:01 -0600
User-agent: Thunderbird 2.0.0.16 (Macintosh/20080707)

address@hidden wrote:
In json.el, the 'json-read-number' function is intended to read the
textual representation of Javascript numbers.

(defun json-read-number ()
  "Read the JSON number following point.
N.B.: Only numbers which can fit in Emacs Lisp's native number
representation will be parsed correctly."
  (if (char-equal (json-peek) ?-)
      (progn
        (json-advance)
        (- 0 (json-read-number)))
    (if (looking-at "[0-9]+\\([.][0-9]+\\)?\\([eE][+-]?[0-9]+\\)?")
        (progn
          (goto-char (match-end 0))
          (string-to-number (match-string 0)))
      (signal 'json-number-format (list (point))))))

The Javascript spec
(http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Literals#Floating-Point_Literals)
says the following about floating-point numbers:

| A floating-point literal can have the following parts:
| | * A decimal integer which can be signed (preceded by "+" or "-"),
|     * A decimal point ("."),
|     * A fraction (another decimal number),
| * An exponent. | | The exponent part is an "e" or "E" followed by an integer, which can
| be signed (preceded by "+" or "-"). A floating-point literal must have
| at least one digit and either a decimal point or "e" (or "E").
This means that

  1.

is a valid floating point-literal per the spec, but the regular
expression above does not match the complete text---the regular
expression requires digits after the decimal point.  This ends up
matched as a simple integer, leaving the decimal point in the input
stream and causing a later syntax error.  Similarly

  .1

is a valid floating point-literal illegal that Emacs rejects, because
the regular expression requires digits before the decimal point.
Testing with the error console in Firefox confirms that the two
examples above are valid syntax.

The parser function needs to be fixed to handle the complete syntax.

It also means that "+1" is valid but not recognized.  That's easy to fix:

  (cond ((char-equal (json-peek) ?-)
         (json-advance)
         (- (json-read-number)))
        ((char-equal (json-peek) ?+)
         (json-advance)
         (json-read-number))
        ((looking-at "[0-9]+\\([.][0-9]+\\)?\\([eE][+-]?[0-9]+\\)?")
...)
        (t (signal 'json-number-format (list (point)))))

The spec you cite also says:

| More succinctly, the syntax is:
|
| [digits][.digits][(E|e)[(+|-)]digits]

which would be translated literally as

"\\([0-9]+\\)?\\(\\.[0-9]+\\)?\\([Ee][+-]?[0-9]+\\)?"

The only difference between that and the regexp in json-read-number is
the optionality of the leading digits and the representation of the
decimal point.

But the potential problem with changing the regexp like that is that it
now matches the empty string, which the spec does not allow:

| A floating-point literal must have at least one digit and either a decimal point or "e" (or "E").

So, does this give the desired results:

(defun json-read-number ()
  "Read the JSON number following point.
N.B.: Only numbers which can fit in Emacs Lisp's native number
representation will be parsed correctly."
  (cond ((char-equal (json-peek) ?-)
         (json-advance)
         (- (json-read-number)))
        ((char-equal (json-peek) ?+)
         (json-advance)
         (json-read-number))
        ((and (looking-at "\\([0-9]+\\)?\\(\\.[0-9]+\\)?\\([Ee][+-]?[0-9]+\\)?")
              (or (match-beginning 1) (match-beginning 2) (match-beginning 3)))
         (goto-char (match-end 0))
         (string-to-number (match-string 0)))
        (t (signal 'json-number-format (list (point))))))

--
Kevin Rodgers
Denver, Colorado, USA








reply via email to

[Prev in Thread] Current Thread [Next in Thread]