This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFC] Suggested ways to remove the need for xm-go32.h
- From: Mark Kettenis <kettenis at gnu dot org>
- To: eliz at gnu dot org
- Cc: gdb-patches at sources dot redhat dot com
- Date: Sun, 19 Sep 2004 13:44:28 +0200 (CEST)
- Subject: Re: [RFC] Suggested ways to remove the need for xm-go32.h
- References: <01c49d82$Blat.v2.2.2$23875ec0@zahav.net.il>
Date: Sat, 18 Sep 2004 16:18:31 +0300
From: "Eli Zaretskii" <eliz@gnu.org>
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