From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21193 invoked by alias); 24 Sep 2004 10:48:50 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 21160 invoked from network); 24 Sep 2004 10:48:47 -0000 Received: from unknown (HELO balder.inter.net.il) (192.114.186.15) by sourceware.org with SMTP; 24 Sep 2004 10:48:47 -0000 Received: from zaretski ([80.230.143.223]) by balder.inter.net.il (Mirapoint Messaging Server MOS 3.3.7-GR) with ESMTP id DUN44802 (AUTH halo1); Fri, 24 Sep 2004 12:48:45 +0200 (IST) Date: Fri, 24 Sep 2004 10:48:00 -0000 From: "Eli Zaretskii" To: gdb-patches@sources.redhat.com Message-ID: <01c4a223$Blat.v2.2.2$e47a6c80@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 In-reply-to: <20040923211643.GA22829@trixie.casa.cgf.cx> (message from Christopher Faylor on Thu, 23 Sep 2004 17:16:43 -0400) Subject: Re: [RFC] Suggested ways to remove the need for xm-go32.h Reply-to: Eli Zaretskii References: <01c49d82$Blat.v2.2.2$23875ec0@zahav.net.il> <20040923050534.GA11936@trixie.casa.cgf.cx> <200409232058.i8NKwHg4009186@elgar.sibelius.xs4all.nl> <20040923211643.GA22829@trixie.casa.cgf.cx> X-SW-Source: 2004-09/txt/msg00393.txt.bz2 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 > > 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 > > > > 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.