Re: [RFC] Suggested ways to remove the need for xm-go32.h

["Eli Zaretskii" <eliz at gnu dot org>]

Thanks to everybody for useful feedback.

Let me try to summarize this discussion.

It sounds like everyone agreed that the solution to GDBINIT_FILENAME
is to have a list of file names and try them in sequence until
succeeded.  I'm okay with that, but I worry a bit whether this won't
break some people who have both .gdbinit and gdb.ini in the same
directory (for example, if some distribution comes with both to be
useful on different systems).  I guess such situations are rare,
though.

I also didn't read any objections to have GDB support both NL-only and
CRLF style source files.

So, unless someone voices objections in the next few days, I'm going
to code these two changes.

About fopen-bin.h: As I said before, I'm okay with writing wrapper
functions, but let me first reply to the few comments raised during
the discussions.

> Date: Thu, 23 Sep 2004 01:05:34 -0400
> From: Christopher Faylor <me@cgf.cx>
> 
> Is a wrapper function more better than just doing:
> 
> #ifdef USEB
> #define READ "rb"
> #else
> #define READ "r"
> #endif
> 
>   fopen ("foo", READ)

We do that now; the problem is, where should USEB or its equivalent be
defined.

A wrapper function will do something like this:

    FILE *fp = fopen (file, "rb");
    if (!fp)
      fp = fopen (file, "r");
    return fp;

This assumes that if the `b' qualifier is not supported, `fopen'
either fails for "rb" or silently ignores `b'.

> It's similar to how we handle the similar use of O_BINARY now.

The difference between O_BINARY and "rb" is that the former is defined
in a well-known system header on systems that need it, while there's
no similar macro for the latter.

> Out of curiousity is O_BINARY mandated by ISO C?  I suspect not.

O_BINARY is a Posix thing (ANSI C doesn't know about `open' at all),
so ISO C has nothing to say about it.  But even if you look at the
latest Posix (well, the draft I have here), you will not find O_BINARY
there.  So Posix systems are not allowed to distinguish between text
and binary files.

> >4.  DIRNAME_SEPARATOR: The DOS-specific definition can be put either
> >    in defs.h or local to the only file that uses it (source.c).
> 
> This could be determined at configure time couldn't it?  You could
> play with the path to see if a colon or semicolon does the desired
> thing and then set it appropriately via config.in.

I don't think it's a good idea.  First, this requires to _run_ a test
program, not just compile/link it, which is bad for cross-compiling.
And second, it sounds silly to me to make an autoconf test for a
single supported port which will _always_ need it.

> On Thu, Sep 23, 2004 at 10:58:17PM +0200, Mark Kettenis wrote:
> >   Date: Thu, 23 Sep 2004 01:05:34 -0400
> >   From: Christopher Faylor <me@cgf.cx>
> >
> >   On Sat, Sep 18, 2004 at 04:18:31PM +0300, Eli Zaretskii wrote:
> >   >Here's how I propose to deal with each one of these:
> >   >
> >   >1.  fopen-bin.h: I suggest to modify the default definitions of the
> >   >    FOPEN_* macros on defs.h to the ANSI/ISO-compatible "rb", "wb",
> >   >    etc. strings that include the "b" modifier.  Since we already
> >   >    require ISO C compliance from all the ports, such a default must
> >   >    DTRT.  Once the defaults are changed, there should be no need to
> >   >    use fopen-bin.h neither in the DJGPP nor in the Cygwin port.
> >
> >   I'd be happy to see this but I see that later in the thread that we
> >   seem to be converging on a wrapper function.
> >
> >I still favour the wrapper function, since that's more robust, but I
> >wouldn't really object if we'd use exactly the same configure magic as
> >BFD does.  Note that that imposes a burden on the maintainers of
> >DOS-ish systems to keep it in sync with BFD.
> 
> i.e.,
> 
>   dnl See whether we need to use fopen-bin.h rather than fopen-same.h.
>   AC_DEFUN([BFD_BINARY_FOPEN],
>   [AC_REQUIRE([AC_CANONICAL_SYSTEM])
>   case "${host}" in
>   changequote(,)dnl
>   *-*-msdos* | *-*-go32* | *-*-mingw32* | *-*-cygwin* | *-*-windows*)
>   changequote([,])dnl
>     AC_DEFINE(USE_BINARY_FOPEN, 1, [Use b modifier when opening binary files?]) ;;
>   esac])dnl

That's exactly something I find silly: there's a known fixed list of
configurations that need USE_BINARY_FOPEN to be defined, so why should
we put it in configure.in instead of having it directly in config.in?
(Btw, in our case, the list of configurations that need that will be
much shorter.)

> Since I've never had to worry about this in binutils, it's probably ok
> but, these days, I think it's backwards to put the burden on the
> maintainers of the modern systems (i.e., cygwin and DJGPP) at the
> expense of the hypothetical ancient ones.  Why not let the Ultrix
> maintainer worry about this rather than the cygwin/djgpp maintainers?

Right.  The above was justified 10 years ago, when the systems that
supported the binary flag were the minority, but going the same way
today sounds not such a good idea.

> A simple way to see what the preference is would be to poll the PATH
> environment variable.  But, then, it's easy enough to must make it ';'
> for the one host that needs it by using a similar technique to the
> above.

Exactly!  And for the same reasons as I mentioned above, since only
one well-known system needs DIRNAME_SEPARATOR to be ';', I suggest to
define it in a single place conditioned by that system.

So my preferences are: to use "rb" and "wb" unconditionally, and to
define DIRNAME_SEPARATOR for DJGPP in defs.h.  However, if Mark would
still like wrappers for the former, I'll do it that way.

If anyone has further reservations about that, please speak up.