bug#24892: {s, }brk removed from FreeBSD 11.x and later, arm64 architecture

[Eli Zaretskii]

> Cc: 24892@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Wed, 9 Nov 2016 17:47:19 -0800
> 
> On 11/09/2016 07:49 AM, Eli Zaretskii wrote:
> > we could lift the implementation from
> > system_process_attributes, we report there the process memory size.
> 
> That number is not that relevant to the intent of memory-limit, and on 
> my platform (Fedora 24 x86-64) returning 0 is a better approximation. 

That's strange: how can zero be a useful approximation of the memory
footprint of a running process?  What does memory-limit return on your
system?

> That being said, we can add some help along those lines, in the attached 
> patch, slightly modified from the original to suggest (alist-get 'vsize 
> (process-attributes (emacs-pid))) for users who prefer the virtual 
> memory size.

Thanks, I think we should have a function that does this in, say,
simple.el, under a name such as emacs-memory-size, and point to that
in the obsolescence note.

>  DEFUN ("memory-limit", Fmemory_limit, Smemory_limit, 0, 0, 0,
> -       doc: /* Return the address of the last byte Emacs has allocated, 
> divided by 1024.
> -This may be helpful in debugging Emacs's memory usage.
> -We divide the value by 1024 to make sure it fits in a Lisp integer.  */)
> +       doc: /* Return zero.  */)
>    (void)
>  {
> -  Lisp_Object end;
> -
> -#if defined HAVE_NS || !HAVE_SBRK
> -  /* Avoid warning.  sbrk has no relation to memory allocated anyway.  */
> -  XSETINT (end, 0);
> -#else
> -  XSETINT (end, (intptr_t) (char *) sbrk (0) / 1024);
> -#endif
> -
> -  return end;
> +  return make_number (0);
>  }

That's too drastic, IMO.  We will eventually do that, in time, but
doing that in the same commit that makes the function obsolete is too
soon.