From: Mark Kettenis <kettenis@gnu.org>
To: eliz@gnu.org
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFC] Suggested ways to remove the need for xm-go32.h
Date: Sun, 19 Sep 2004 11:44:00 -0000 [thread overview]
Message-ID: <200409191144.i8JBiSA7045711@elgar.sibelius.xs4all.nl> (raw)
In-Reply-To: <01c49d82$Blat.v2.2.2$23875ec0@zahav.net.il> (eliz@gnu.org)
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
next prev parent reply other threads:[~2004-09-19 11:44 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-18 13:21 Eli Zaretskii
2004-09-19 11:44 ` Mark Kettenis [this message]
2004-09-20 3:33 ` Eli Zaretskii
2004-09-22 20:21 ` Michael Chastain
2004-09-23 4:51 ` Eli Zaretskii
2004-09-23 6:02 ` Michael Chastain
2004-09-23 8:14 ` Corinna Vinschen
2004-09-23 5:03 ` Christopher Faylor
2004-09-23 6:30 ` Michael Chastain
2004-09-23 8:02 ` Corinna Vinschen
2004-09-24 10:51 ` Eli Zaretskii
2004-09-24 14:35 ` Andrew Cagney
2004-09-23 13:56 ` Christopher Faylor
2004-09-23 17:20 ` Michael Chastain
2004-09-23 17:24 ` Christopher Faylor
2004-09-23 15:18 ` Joel Brobecker
2004-09-23 17:57 ` Daniel Jacobowitz
2004-09-24 15:05 ` Andrew Cagney
2004-09-25 16:43 ` Eli Zaretskii
2004-09-26 18:38 ` Mark Kettenis
2004-09-27 2:29 ` Daniel Jacobowitz
2004-09-23 20:58 ` Mark Kettenis
2004-09-23 21:14 ` Christopher Faylor
2004-09-24 10:48 ` Eli Zaretskii
2004-09-24 12:23 ` Corinna Vinschen
2004-09-24 13:39 ` Andreas Schwab
2004-09-24 19:51 ` Christopher Faylor
2004-09-24 21:16 ` Christopher Faylor
2004-09-24 21:32 ` Andreas Schwab
2004-09-24 13:40 ` Eli Zaretskii
2004-09-24 16:49 ` Ian Lance Taylor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200409191144.i8JBiSA7045711@elgar.sibelius.xs4all.nl \
--to=kettenis@gnu.org \
--cc=eliz@gnu.org \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox