Re: [SH] regs command

Maciej W. Rozycki
2012-05-21T23:36:47Z

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