* doc/extend.texi (Arrays and pointers implementation): Document

        behavior of pointer/integer conversion.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@44784 138bc75d-0d04-0410-961f-82ee72b054a4

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index fdf3494..9d9bbe1 100644 (file)
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2001-08-10  Richard Henderson  <rth@redhat.com>
+
+       * doc/extend.texi (Arrays and pointers implementation): Document
+       behavior of pointer/integer conversion.
+
 2001-08-10  Ulrich Weigand  <uweigand@de.ibm.com>
  
        * glimits.h (__LONG_MAX__): Add s390x as 64-bit architecture.

diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index cc2fda7..12b9e71 100644 (file)
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -201,6 +201,26 @@ IEC 60559 conformant implementation (F.9).}
 @cite{The result of converting a pointer to an integer or
 vice versa (6.3.2.3).}
 
+A cast from pointer to integer discards most-significant bits if the
+pointer representation is larger than the integer type, sign-extends
+if the pointer representation is smaller than the integer type, otherwise
+the bits are unchanged.
+@c ??? We've always claimed that pointers were unsigned entities.
+@c Shouldn't we therefore be doing zero-extension?  If so, the bug
+@c is in convert_to_integer, where we call type_for_size and request
+@c a signed integral type.  On the other hand, it might be most useful
+@c for the target if we extend according to POINTERS_EXTEND_UNSIGNED.
+
+A cast from integer to pointer discards most-significant bits if the
+pointer representation is smaller than the integer type, extends according
+to the signedness of the integer type if the pointer representation
+is larger than the integer type, otherwise the bits are unchanged.
+
+When casting from pointer to integer and back again, the resulting
+pointer must reference the same object as the original pointer, otherwise
+the behavior is undefined.  That is, one may not use integer arithmetic to
+avoid the undefined behavior of pointer arithmetic as proscribed in 6.5.6/8.
+
 @item
 @cite{The size of the result of subtracting two pointers to elements
 of the same array (6.5.6).}