There are places in ralloc.c where a for loop is used to express a loop,
and places where a while loop is used with the increment operation at the
end of it.  This would just simplify all code so that it was consistently
using a for loop for this purpose.

Without this patch here is a good usage of for:

  heap_ptr heap;

  for (heap = last_heap; heap; heap = heap->prev)
    {
      if (heap->start <= address && address <= heap->end)
return heap;
    }

Here is a usage of while that should be a for loop like the previous
example:

  bloc_ptr p = first_bloc;

  while (p != NIL_BLOC)
    {
      /* Consistency check. Don't return inconsistent blocs.
Don't abort here, as callers might be expecting this, but
callers that always expect a bloc to be returned should abort
if one isn't to avoid a memory corruption bug that is
difficult to track down.  */
      if (p->variable == ptr && p->data == *ptr)
return p;

      p = p->next;
    }

Recommended new code:

  bloc_ptr p;

  for (p = first_bloc; p != NIL_BLOC; p = p->next)
    {
      /* Consistency check. Don't return inconsistent blocs.
Don't abort here, as callers might be expecting this, but
callers that always expect a bloc to be returned should abort
if one isn't to avoid a memory corruption bug that is
difficult to track down.  */
      if (p->variable == ptr && p->data == *ptr)
return p;
    }

This style exact loop is even used later on (line 509 in
update_heap_bloc_correspondence()):

  /* Advance through blocs one by one.  */
  for (b = bloc; b != NIL_BLOC; b = b->next)

-- 
Chris Gregory

On Sat, Jan 7, 2017 at 12:30 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> tags 25332 notabug
> close 25332
> thanks
>
> > From: Chris Gregory <czipperz@gmail.com>
> > Date: Mon, 02 Jan 2017 00:26:07 -0800
> >
> > This patch changes while loops to for loops to make the code more
> > consistent.
>
> I don't think I understand the rationale.  Why is using 'while'
> inconsistent?
>
> In any case, please don't bother making style changes in ralloc.c, as
> that file should almost never be used in Emacs, except in some
> marginal configurations, and we actually would like to get rid of it
> altogether.  It's therefore a waste of effort to try to make its style
> better.
>