Re: [RFC] Suggested ways to remove the need for xm-go32.h

[Christopher Faylor <me at cgf dot cx>]

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