From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23167 invoked by alias); 23 Sep 2004 05:03:34 -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 23157 invoked from network); 23 Sep 2004 05:03:32 -0000 Received: from unknown (HELO cgf.cx) (66.30.17.189) by sourceware.org with SMTP; 23 Sep 2004 05:03:32 -0000 Received: by cgf.cx (Postfix, from userid 201) id B62B31B3F8; Thu, 23 Sep 2004 01:05:34 -0400 (EDT) Date: Thu, 23 Sep 2004 05:03:00 -0000 From: Christopher Faylor To: gdb-patches@sources.redhat.com Subject: Re: [RFC] Suggested ways to remove the need for xm-go32.h Message-ID: <20040923050534.GA11936@trixie.casa.cgf.cx> Mail-Followup-To: gdb-patches@sources.redhat.com References: <01c49d82$Blat.v2.2.2$23875ec0@zahav.net.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c49d82$Blat.v2.2.2$23875ec0@zahav.net.il> User-Agent: Mutt/1.4.1i X-SW-Source: 2004-09/txt/msg00363.txt.bz2 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 have a vague dislike for using wrapper functions if you can get away without using them. It's one less thing in a backtrace. Is a wrapper function more better than just doing: #ifdef USEB #define READ "rb" #else #define READ "r" #endif fopen ("foo", READ) Or is that an unacceptable use of a macro? It's similar to how we handle the similar use of O_BINARY now. Out of curiousity is O_BINARY mandated by ISO C? I suspect not. MichaelC has indicated which systems support "rb". Is there any way to somehow figure out if this is supported for the whole list of supported targets? Or can we try going without the wrapper function and move to a wrapper function when someone complains? >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. I wouldn't mind just maintaining a list of filenames that gdb uses, as Mark suggests. >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. I think understanding files with CRLF is a good idea. Doesn't gcc do this now? *pause* Yep. It does. We might as well be consistent. >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. cgf