From 9b2b2b07d2743e14f45de7256856c9099dbc81ea Mon Sep 17 00:00:00 2001 From: rth Date: Sat, 11 Aug 2001 00:53:45 +0000 Subject: [PATCH] * 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 --- gcc/ChangeLog | 5 +++++ gcc/doc/extend.texi | 20 ++++++++++++++++++++ 2 files changed, 25 insertions(+) diff --git a/gcc/ChangeLog b/gcc/ChangeLog index fdf3494..9d9bbe1 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,8 @@ +2001-08-10 Richard Henderson + + * doc/extend.texi (Arrays and pointers implementation): Document + behavior of pointer/integer conversion. + 2001-08-10 Ulrich Weigand * 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 --- 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).} -- 2.7.4