In article <1993May19.233056.11571@parc.xerox.com>, ellis@parc.xerox.com (John Ellis) writes:
|> [This is a repost.]
|>
|> There is a difference between ANSI C and the ARM that is not listed in
|> the ARM section 18.2:
|>
|>     The ARM specifically allows a pointer to be cast to an integer of
|>     sufficient size and back again, yielding the same pointer value
|>     (section 5.4).
|>
|>     The ANSI C standard states that casting a pointer to an integer and back
|>     will not necessarily yield the same pointer value (3.3.4, Rationale 3.3.4).
|>
|> Has there been committee discussion about this difference? If not,
|> should there be?
|>
|> If C++ followed the ANSI C behavior, then C++ would not require any
|> additional rules for correct use of garbage collection.  With the
|> current ARM definition, garbage collection requires such casts to be
|> prohibited.
|>

What the C standard actually says is:

 A pointer may be converted to an integral type.  The
 size of integer required and the result are implementation
 defined.  If the space provided is not long enough the
 behavior is undefined.

 An arbitrary integer may be converted to a pointer. The result
 is implementation defined.

 [footnote: The mapping functions for converting a pointer
 to an integer or an integer to a pointer are intended to
 be consistent with the addressing structure of the
 execution environment]


It's pretty clear to me that the intent of the ARM's words
and the C standard's is essentially the same and I think the ARM's are
clearer.  But they aren't identical and you're entitled to read them
differently.

But the effect of the conversion from pointer to a sufficiently
large integer and back are clearly implementation defined by the C standard.
That means vendors are required to say what the conversions do,
and the footnote gives a strong (although not binding) hint about
what they should say.

And on many (all?) implementations a conversion from pointer to
to sufficiently large integral types and back is implementation defined
to be the identity.

If you want to say that GC requires avoiding this conversion fine.  But
if you want vendors to change the implementation defined behavior of
this construct then I think you're asking for way too much.  And if you
want the standard to make this behavior undefined rather than implementation
defined you're not doing the C++ user community a service.

   -- Jerry Schwarz

jss@lucid.com (Jerry Schwarz) writes:

    If you want to say that GC requires avoiding this conversion fine.
    But if you want vendors to change the implementation defined
    behavior of this construct then I think you're asking for way too
    much.  And if you want the standard to make this behavior
    undefined rather than implementation defined you're not doing the
    C++ user community a service.

We have no intention of requesting a change to the language.  We just
wanted to know if an apparent difference in specification between ARM
C++ and ANSI C was intentional and what position the ANSI standard
might take.   I just mentioned GC as a way of motivating the reason
for requesting a clarification.

In article <1993May19.233056.11571@parc.xerox.com> ellis@parc.xerox.com (John Ellis) writes:
|[This is a repost.]
|
|There is a difference between ANSI C and the ARM that is not listed in
|the ARM section 18.2:
|
|    The ARM specifically allows a pointer to be cast to an integer of
|    sufficient size and back again, yielding the same pointer value
|    (section 5.4).
|
|    The ANSI C standard states that casting a pointer to an integer and back
|    will not necessarily yield the same pointer value (3.3.4, Rationale 3.3.4).

The ARM is a reference manual, not a standards specification.  If one
tries to read into the ARM the level of legalese required of a standard,
one is going to be disappointed.  I hope and presume that the standards
committee is making the ARM language more rigorous, so that it can pass
muster as an international standard.  If they intend to leave ARM language
as is and call that the "standard" then they're making a big mistake.

Note that the ARM language would require different behavior of different
implementations.  Those implementations where integers are "big enough"
have to support the cast, those implementation where they are not
"big enough" do not.  If you take these comments seriously, then one
has a standard that makes different requirements on different implementations,
and thus is a non-standard standard.

This would be silly, IMHO.  A standard calls out specifications that all
implementations are required to meet, or which no implementation is
required to meet.

Further, note that it is the *implementation* that defines what the integer
is, what the pointer is, and therefore whether the two are "big enough"
or not.  The machine sizes of these things are the sizes of the *abstact*
machine that the implementation defines itself to run on.  The actual
hardware machine may have different sizes for these things, or differing
sizes for these things.  For example, on x86 family machines, the CPUs
can very naturally have integer sizes of 16 or 32 bits, and can have
pointer sizes of 16, 32, or 48 bits.  It is up to the implementation
then, to define whether or not an integer is "big enough" and what
"big enough" means.  Clearly if one has a copying GC implementation,
then even given 32-bit pointers and 32-bit integers, the 32-bit integers
are still not "big enough".  But, if the integers were 64-bits, then
a natural implementation of the pointer/int casts would be easily
possible.

[This is a repost.]

There is a difference between ANSI C and the ARM that is not listed in
the ARM section 18.2:

    The ARM specifically allows a pointer to be cast to an integer of
    sufficient size and back again, yielding the same pointer value
    (section 5.4).

    The ANSI C standard states that casting a pointer to an integer and back
    will not necessarily yield the same pointer value (3.3.4, Rationale 3.3.4).

Has there been committee discussion about this difference? If not,
should there be?

If C++ followed the ANSI C behavior, then C++ would not require any
additional rules for correct use of garbage collection.  With the
current ARM definition, garbage collection requires such casts to be
prohibited.