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

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

Re: Is X'ABCD' notation of general interest?


From: Thien-Thi Nguyen
Subject: Re: Is X'ABCD' notation of general interest?
Date: Sun, 12 Apr 2009 13:45:53 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

() florian <lorian@fsavigny.de>
() Thu, 9 Apr 2009 03:05:03 -0700 (PDT)

   The X'ABCD' notation represents arbitrary bytes as their
   two-digit hexadecimal representation, which produces strings
   that have double the size and can be passed over the command
   line (SQLite uses this).  Does anybody think that functions to
   handle that (I have round-trip tested them) would be of general
   interest, so that posting them on gnu.emacs.sources would make
   sense? (Just don't want to clutter public space needlessly.)

You may be interested in knowing that Emacs can `read' hex if the
number has the "#x" prefix.

(let ((standard-input "#x0a"))
  (read))
=> 10

Something like the following (completely untested) code might be
faster than using `string-to-number':

(defvar small "#x......"
  "Fixed-size buffer holding a small hex number to be `read'.")

(defun next-small-X-quote-hex-quote-number ()
  "Return the next parsed X'HEX-NUMBER' or nil."
  (let ((ok (- (length small) 2))  ;; -2 for "#x"
        b e)
    (when (re-search-forward "X'[0-9a-fA-F]+'" nil t)
      (setq b (+ 2 (match-beginning 0))
            e (1- (point)))
      (if (not (< ok (- e b)))
          ;; "fast path" (one hopes, one wonders)
          (do ((w 2 (1+ w)))
              ((= b e) (let ((standard-input small))
                         (read)))
            (aset small w (char-before (incf b))))
        ;; fallback for big strings
        (string-to-number (buffer-substring b e) 16)))))

This is the limit (performance wise) if the buffer is not to be
modified.  If the buffer can be modified, you can go even faster
if you rewrite the "X'" as "x#" directly and set `standard-input'
to `(current-buffer)' (plus usual performance tweaks).  Of course,
if speed matters not, then no worries, feel free to ignore...

thi




reply via email to

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