Re: [SH] regs command

["Maciej W. Rozycki" <macro@codesourcery.com>]

On Fri, 18 May 2012, Tom Tromey wrote:

> Maciej>  While I agree that this command deprecation case may not be important 
> Maciej> enough to make a decision on an internal API change weeks before a 
> Maciej> release, that does not mean the problem is not there.
> 
> Yeah, I agree, there is a problem -- it is encountered infrequently
> enough that we can usually pretend it isn't there.  There's also some
> places that were designed to avoid dependency problems, like the way
> command list roots are statically allocated.

 Yeah, let's pretend it isn't there. ;)

> Basing the dependencies on file names doesn't seem robust.  It works in
> this case; but I don't think there is a reason to believe it will always
> be a workable approach.

 Yes, this is fragile to say at least, I agree.

> I think one way to fix it would be to have the code express the
> dependencies.  This might be tricky to maintain, though I suppose with
> enough assertions it could be robust.

 Hmm, I gave it some thinking and it looks to me like a functional 
programming problem to solve (e.g. AC_REQUIRE in autoconf-speak; I didn't 
really do any functional programming beyond that).  This may not be 
possible to express in C in a very elegant way, but I can imagine 
retaining the current init.c arrangement/scriptery, but in addition to 
that letting initialisers call one another.

 Then in each initialiser we could have:

void
_initialize_foo (void)
{
  static int initialized;

  if (initialized > 0)
    return;
  else if (initialized < 0)
    internal_error (__FILE__, __LINE__, _("initialization loop"));
  else
    initialized = -1;

[...]

  initialized = 1;
}

We might be able to hide this stuff in some macros so as to avoid 
repeating it across all files (and risking mistakes).  This could avoid 
the need to copy these annoying prototypes to shut up GCC for each 
initialiser as well (but then the scripts could simply make init.h 
instead).

  Maciej