From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15419 invoked by alias); 19 Sep 2004 11:44:32 -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 15399 invoked from network); 19 Sep 2004 11:44:27 -0000 Received: from unknown (HELO walton.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org with SMTP; 19 Sep 2004 11:44:27 -0000 Received: from elgar.sibelius.xs4all.nl (elgar.sibelius.xs4all.nl [192.168.0.2]) by walton.sibelius.xs4all.nl (8.13.0/8.13.0) with ESMTP id i8JBiOAl023826; Sun, 19 Sep 2004 13:44:24 +0200 (CEST) Received: from elgar.sibelius.xs4all.nl (localhost [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6) with ESMTP id i8JBiSjZ045714; Sun, 19 Sep 2004 13:44:28 +0200 (CEST) (envelope-from kettenis@elgar.sibelius.xs4all.nl) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6/Submit) id i8JBiSA7045711; Sun, 19 Sep 2004 13:44:28 +0200 (CEST) Date: Sun, 19 Sep 2004 11:44:00 -0000 Message-Id: <200409191144.i8JBiSA7045711@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: eliz@gnu.org CC: gdb-patches@sources.redhat.com In-reply-to: <01c49d82$Blat.v2.2.2$23875ec0@zahav.net.il> (eliz@gnu.org) Subject: Re: [RFC] Suggested ways to remove the need for xm-go32.h References: <01c49d82$Blat.v2.2.2$23875ec0@zahav.net.il> X-SW-Source: 2004-09/txt/msg00300.txt.bz2 Date: Sat, 18 Sep 2004 16:18:31 +0300 From: "Eli Zaretskii" I looked at what xm-go32.h does, and here are my suggestions for eliminating the need for it. If these suggestions are okayed, I will post patches to do that, and then xm-go32.h could be removed (as well as, I hope, xm-cygwin.h, so Chris, please see if these suggestions are okay for Cygwin). Currently, xm-go32.h does this: . #include's fopen-bin.h . #define's GDBINIT_FILENAME to "gdb.ini" . #define's CRLF_SOURCE_FILES . #define's DIRNAME_SEPARATOR to ';' 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. Thus far, we've required a ISO C compliant *compiler*, but not strictly ISO C compliant *libraries*. The reasoning behind this is that it's easy to replace the compiler (with gcc), but not so easy to replace the system libraries. I'm not really sure that all supported systems support the "b" modifier. So I don't think we can do this. I think it'd be better to have wrapper functions that try to open the file using the "b" modifier, and if that fails, retry without. It's a bit more work, but it should be more robust. 2. GDBINIT_FILENAME: This one is currently used by top.c and cli-cmds.c. The latter uses the definition in a doc string for the `source' command, while the former uses GDBINIT_FILENAME for the value of the global var gdbinit[] which is then referenced in main.c. My suggestion is to move the definition of GDBINIT_FILENAME to defs.h, conditioned by a suitable DJGPP-specific #ifdef. Alternatively, we could make the definition of GDBINIT_FILENAME local to top.c, and modify cli-cmds.c to use the global variable gdbinit[] instead of the macro. Why not have a list of files to try? That would mean we'd always try "gdb.ini" if ".gdbinit" fails, even on Unix. 3. CRLF_SOURCE_FILES: Here I suggest to make GDB understand CR-LF style files on all supported systems. Surely with today's proliferation of networked drives and compilers that support CR-LF files even on Unix, one can never know whether the source file comes from a drive exported by some Windows server or one that was edited by some Windows editor that added CR characters to each line. In addition to compilers, other programs support CR-LF files on Posix systems; examples include Emacs and Texinfo's Info reader. If this suggestion is accepted, I suggest to make the code that is currently conditioned by #ifdef CRLF_SOURCE_FILES be the only code path in the files that use it (event-top.c, source.c, and top.c) and remove the conditional itself. Sounds like a good idea to me. 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). We should probably include "filenames.h" and base the definition on HAVE_DOS_BASED_FILE_SYSTEM. I'm somewhat in favor of doing that only locally in source.c. Mark