bug#24378: [PATCH] Remove obsolete comment from FETCH_MULTIBYTE_CHAR documentation

[Michal Nazarewicz]

* src/buffer.h (FETCH_MULTIBYTE_CHAR): STRING_CHAR macro no longer
unifies characters so the comment about byte-length changing is no
longer accurate; remove it.  While at it, change the function to use
BYTE_POS_ADDR instead of open-coding it.
---
 src/buffer.h | 15 ++-------------
 1 file changed, 2 insertions(+), 13 deletions(-)

diff --git a/src/buffer.h b/src/buffer.h
index 87b7cee..fa4866e 100644
--- a/src/buffer.h
+++ b/src/buffer.h
@@ -1182,23 +1182,12 @@ buffer_has_overlays (void)
 
 /* Return character code of multi-byte form at byte position POS.  If POS
    doesn't point the head of valid multi-byte form, only the byte at
-   POS is returned.  No range checking.
-
-   WARNING: The character returned by this macro could be "unified"
-   inside STRING_CHAR, if the original character in the buffer belongs
-   to one of the Private Use Areas (PUAs) of codepoints that Emacs
-   uses to support non-unified CJK characters.  If that happens,
-   CHAR_BYTES will return a value that is different from the length of
-   the original multibyte sequence stored in the buffer.  Therefore,
-   do _not_ use FETCH_MULTIBYTE_CHAR if you need to advance through
-   the buffer to the next character after fetching this one.  Instead,
-   use either FETCH_CHAR_ADVANCE or STRING_CHAR_AND_LENGTH.  */
+   POS is returned.  No range checking. */
 
 INLINE int
 FETCH_MULTIBYTE_CHAR (ptrdiff_t pos)
 {
-  unsigned char *p = ((pos >= GPT_BYTE ? GAP_SIZE : 0)
-                     + pos + BEG_ADDR - BEG_BYTE);
+  unsigned char *p = BYTE_POS_ADDR (pos);
   return STRING_CHAR (p);
 }
 
-- 
2.8.0.rc3.226.g39d4020