This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
[RFC] Suggested ways to remove the need for xm-go32.h
- From: "Eli Zaretskii" <eliz at gnu dot org>
- To: gdb-patches at sources dot redhat dot com
- Date: Sat, 18 Sep 2004 16:18:31 +0300
- Subject: [RFC] Suggested ways to remove the need for xm-go32.h
- Reply-to: Eli Zaretskii <eliz at gnu dot 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.
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.
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.
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).
Comments and discussion are welcome.