bug#6283: doc/lispref/searching.texi reference to octal code `0377' correct?

[Kevin Rodgers]

MON KEY wrote:
> On Thu, May 27, 2010 at 2:10 PM, Eli Zaretskii <eliz@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