[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issues with Windows gcc -mno-cygwin (Mingw)
From: |
Benjamin Riefenstahl |
Subject: |
Re: Issues with Windows gcc -mno-cygwin (Mingw) |
Date: |
20 Mar 2003 17:21:57 +0100 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
Hi Jason, Eli,
Jason Rumney <address@hidden> writes:
> Is it reasonable for the runtime to change _fmode between _start()
> and main()? I think it probably is,
The _start() routine only gets into it, because the Makefile specifies
an explicit entry point in the call to the linker. So _start() is a
modification of the runtime, and Mingw can't garantee anything about
code like that.
> so unless we really need _fmode to be set between _start() and
> main() we should move the assignment to main().
Yes, that seems to work, see attached patch.
> Benjamin Riefenstahl <address@hidden> writes:
> > Emacs doesn't use O_BINARY directly to load files.
"Eli Zaretskii" <address@hidden> writes:
> Oh yes, it does--at least in the DOS_NT versions. Grep the C
> sources for _BINARY, and you will see it yourself.
I have. Emacs does use O_BINARY in some, but not in all places.
Especially Finsert_file_content() doesn't use it in calling
emacs_open() and emacs_open() doesn't add O_BINARY either when it
calls the runtime open().
> So the only issue with binary I/O I'm aware of is with standard
> input and output handles. That's why the code in emacs.c does what
> it does.
Stdin and stdout are not an issue for NT Emacs. The C runtime is not
used by the relevant code there, instead the OS API is used directly.
The text/binary distinction is not relevant anymore at that level.
so long, benny
fmode.diff
Description: Text Data