GNU bug report logs - #6283
doc/lispref/searching.texi reference to octal code `0377' correct?

Previous Next

Full log

Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Kevin Rodgers <kevin.d.rodgers <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#6283: doc/lispref/searching.texi reference to octal code
	`0377' correct?
Date: Sat, 29 May 2010 08:28:57 -0600

MON KEY wrote:
> On Thu, May 27, 2010 at 2:10 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>>> `---- :FILE doc/lispref/searching.texi  (info "(elisp)Regexp Special")
>>>
>>> Shouldn't that be:
>>>
>>> "characters have codes above octal #o377"
>> What's the difference between what's written and what you suggest?
>>
> 
> (string-equal "0377"  "#o377")  => nil
> (string-equal "0377"  "0377")   => t
> (string-equal "#o377" "#o377")  => t

Those strings are not what you seem to think:

(length "0377") ⇒ 4

(length "#o377") ⇒ 5

I think "\377" aka "\xFF" aka "\u00FF" is what you mean.

> The latter forms read syntax being more in keeping with how the lisp
> reader would interpret what the info docs are referring to as `octal
> 0377', and is at in keeping with what is presented in
> (info "(elisp)Integer Basics"):
> 
> (eval #o377) => 255
> 
> What isn't at all clear in the infos in general is that the octal (or
> FTM decimal, hex, etc. representations) for the literal raw-byte \255
> is arrived at with something more like:
> 
> (insert (char-to-string #o17777655))
> 
> (insert (char-to-string #x3fffad))
> 
> (insert (char-to-string 4194221))
> 
> e.g. decimal 4194221 -> octal #o17777655 -> hex #x3fffad
> 
> Without knowing what do with that octal value simply referencing \255
> as octal 0377 or hex X3FFFAD isn't all that informative of itself.
> 
> FWIW It took me a coupla years to figure out what how to frob those
> values into a raw-byte and I still require to relearn it from the docs
> whenever I need to manually revert some raw-bytes or improperly
> encoded bit-rotted text using regexps.
> 


-- 
Kevin Rodgers
Denver, Colorado, USA

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.