Re: VIRT_ADDR_VARIES

[Eli Zaretskii]

> Date: Thu, 10 Nov 2011 00:17:06 -0800
> From: Paul Eggert <address@hidden>
> Cc: address@hidden
> 
> --- src/puresize.h    2011-06-09 19:08:29 +0000
> +++ src/puresize.h    2011-11-10 08:14:27 +0000
> @@ -75,21 +75,7 @@
>  
>  /* Define PURE_P.  */
>  
> -#ifdef VIRT_ADDR_VARIES
> -/* For machines where text and data can go anywhere
> -   in virtual memory.  */
> -
>  extern EMACS_INT pure[];
>  
>  #define PURE_P(obj) \
> - ((PNTR_COMPARISON_TYPE) XPNTR (obj) < (PNTR_COMPARISON_TYPE) ((char *) pure 
> + PURESIZE) \
> -  && (PNTR_COMPARISON_TYPE) XPNTR (obj) >= (PNTR_COMPARISON_TYPE) pure)
> -
> -#else /* not VIRT_ADDR_VARIES */
> -
> -extern char my_edata[];
> -
> -#define PURE_P(obj) \
> -  ((PNTR_COMPARISON_TYPE) XPNTR (obj) < (PNTR_COMPARISON_TYPE) my_edata)
> -
> -#endif /* VIRT_ADDRESS_VARIES */
> +  ((uintptr_t) XPNTR (obj) - (uintptr_t) pure <= PURESIZE)

What is the exact definition of "a pure object"?  Your changes assume
that it is something allocated off pure[], but the original macro,
viz.

  extern char my_edata[];

  #define PURE_P(obj) \
    ((PNTR_COMPARISON_TYPE) XPNTR (obj) < (PNTR_COMPARISON_TYPE) my_edata)

tests something different.  It could, for example, return non-zero for
an object that was not dynamically allocated at all.  It could be that
a test against my_edata was just a means, but we should be sure it
was, before we effectively define VIRT_ADDRESS_VARIES on all
platforms.

Also, isn't it dangerous to have an externally visible symbol with a
name such as `pure'?  What if some system library somewhere also has
such a symbol?