Re: RFA: Support Windows extended error numbers in safe_strerror

Daniel Jacobowitz
2006-02-09T14:57:59Z

On Thu, Feb 09, 2006 at 03:44:07PM +0100, Mark Kettenis wrote:
> > For example, here's a suggestion for what I think is more seamless
> > integration of MinGW and other ``illegal aliens'', here for the
> > `select' issue:
> >
> > int gdb_select (...)
> > {
> > if (select_hook)
> > return (*select_hook) (...);
> > else
> > return select (...);
> > }
> >
> > We make `select_hook' a global pointer to a function, and then MinGW
> > can define its own emulation on win32-something.c and plug its address
> > into `select_hook'.
>
> There is absolutely no reason for this additional complexity. GDB will
> never be able to run on two different hosts at once. Just having two
> different implementations and have configure.host choose the apprpriate
> one will work just fine.

FYI, I'm willing to (and now planning to) go ahead with Mark's plan,
but let me point out a disadvantage to each of these two options...

Right now, we only know of POSIX-ish systems and native Windows as
interesting hopes. I'm sure many of us fervently hope that there are
no others worth going through this for. But is it really wise to
create a host-specific override mechanism which can't scale?

If I do this Mark's way, overriding a function requires putting it into
"posix-hdep.c" and another implementation in "mingw-hdep.c". There's
no way to override only of the functions in posix-hdep.c. If I do it
Eli's way, the function can live anywhere, and is overridden by setting
"function_hook" (or "function_override"?) in _initialize_mingw_hdep.
So a new host could override just select.

Of course there's a flip side. If I do it Eli's way, the default
version has to compile and link. Which happens to be the case for
the two examples we have today, but also a pretty limiting assumption.

Neither of them's perfect. Mark's is marginally less intrusive, and
I'm halfway to an implementation already.

--
Daniel Jacobowitz
CodeSourcery