Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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


  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