From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#18006: Simplify via set_binary_mode Date: Sun, 13 Jul 2014 18:02:21 +0300 Message-ID: <8338e59u9u.fsf@gnu.org> References: <53C1A00C.6050906@cs.ucla.edu> <837g3hanzp.fsf@gnu.org> <53C21918.9020001@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1405263804 20694 80.91.229.3 (13 Jul 2014 15:03:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 13 Jul 2014 15:03:24 +0000 (UTC) Cc: 18006@debbugs.gnu.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jul 13 17:03:16 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1X6LJ6-0006yJ-4r for geb-bug-gnu-emacs@m.gmane.org; Sun, 13 Jul 2014 17:03:16 +0200 Original-Received: from localhost ([::1]:52605 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X6LJ5-0002Z9-6q for geb-bug-gnu-emacs@m.gmane.org; Sun, 13 Jul 2014 11:03:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44315) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X6LIx-0002YA-Iw for bug-gnu-emacs@gnu.org; Sun, 13 Jul 2014 11:03:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X6LIs-0007PF-Bo for bug-gnu-emacs@gnu.org; Sun, 13 Jul 2014 11:03:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:58547) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X6LIs-0007P7-91 for bug-gnu-emacs@gnu.org; Sun, 13 Jul 2014 11:03:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1X6LIr-0004jw-JZ for bug-gnu-emacs@gnu.org; Sun, 13 Jul 2014 11:03:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 13 Jul 2014 15:03:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18006 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 18006-submit@debbugs.gnu.org id=B18006.140526374118161 (code B ref 18006); Sun, 13 Jul 2014 15:03:01 +0000 Original-Received: (at 18006) by debbugs.gnu.org; 13 Jul 2014 15:02:21 +0000 Original-Received: from localhost ([127.0.0.1]:53813 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X6LID-0004ir-3i for submit@debbugs.gnu.org; Sun, 13 Jul 2014 11:02:21 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:47157) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1X6LIA-0004iY-BR for 18006@debbugs.gnu.org; Sun, 13 Jul 2014 11:02:19 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0N8N00D00O9YZZ00@a-mtaout23.012.net.il> for 18006@debbugs.gnu.org; Sun, 13 Jul 2014 18:02:11 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N8N00DXIOFNZU00@a-mtaout23.012.net.il>; Sun, 13 Jul 2014 18:02:11 +0300 (IDT) In-reply-to: <53C21918.9020001@cs.ucla.edu> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:91505 Archived-At: > Date: Sat, 12 Jul 2014 22:28:56 -0700 > From: Paul Eggert > CC: 18006@debbugs.gnu.org > > > . in some places, we want all file I/O to be in binary mode; Gnulib > > doesn't support that > > The Emacs code can continue to use _fmode as before; that part won't be > simplified, but one step at a time. See below. > > . some of the code needs to switch a file descriptor to binary or > > text mode only when the descriptor is or isn't connected to a > > terminal device; Gnulib is ambivalent about that (it always does > > that for MSDOS, and never for Windows) > > binary-io has two interfaces; one (set_binary_mode) always does it, on > all platforms; the other (SET_BINARY) deliberately has no effect on > __DJGPP__ when isatty returns nonzero. Emacs can use either interface, > as it needs. OK. > Should SET_BINARY also should have no effect on MS-Windows > when isatty returns nonzero? No, the SET_BINARY macro does TRT here. > Emacs already uses binary-io, by the way; if this were a problem I > expect we'd already have run into it. We don't currently use binary-io on Windows. > >> /* Don't put CRs in the DOC file. */ > >> -#ifdef MSDOS > >> - _fmode = O_BINARY; > >> -#if 0 /* Suspicion is that this causes hanging. > >> - So instead we require people to use -o on MSDOS. */ > >> - (stdout)->_flag &= ~_IOTEXT; > >> - _setmode (fileno (stdout), O_BINARY); > >> -#endif > >> - outfile = 0; > >> -#endif /* MSDOS */ > >> -#ifdef WINDOWSNT > >> - _fmode = O_BINARY; > >> - _setmode (fileno (stdout), O_BINARY); > >> -#endif /* WINDOWSNT */ > >> + set_binary_mode (fileno (stdout), O_BINARY); > > > > This is wrong: setting _fmode affects all I/O, input and output, not > > just stdout. Gnulib's binary-io doesn't have the equivalent > > functionality. > > If setting _fmode affects all I/O, why does the WINDOWSNT code bother to > call _setmode? Because setting _fmode only affects the open/fopen calls made _after_ the change. It cannot affect standard streams that are opened before 'main' runs. However, I think that we should simply use "rb", "wb", etc. in the calls to 'fopen', and forget all this _fmode stuff. (Btw, are there still standard C libraries we care about that don't support "rb" and "wb"? If not, we could use these on all platforms, without any #ifdefs.) > Conversely, why does make-docfile.c need to set _fmode, > if the intent is "Don't put CRs in the DOC file"; shouldn't it suffice > to call _setmode on stdout? The comment is inaccurate: it actually doesn't want to put CRs in any output files, not just DOC. > > This logic is flawed: if emacs_get_tty failed, then emacs_set_tty > > should not be called as well. > > I was just copying the existing logic. But it's easy to fix while we're > at it; revised patch attached. > > > This will not work with Windows isatty, because it doesn't return 1 > > when fd is connected to a console. > > Thanks, I also tried to address that in the attached patch. Thanks. I have one comment: > +int > emacs_get_tty (int fd, struct emacs_tty *settings) > { > /* Retrieve the primary parameters - baud rate, character size, etcetera. */ > @@ -786,15 +787,16 @@ > HANDLE h = (HANDLE)_get_osfhandle (fd); > DWORD console_mode; > > - if (h && h != INVALID_HANDLE_VALUE) > + if (h && h != INVALID_HANDLE_VALUE && GetConsoleMode (h, &console_mode)) > { > - if (GetConsoleMode (h, &console_mode)) > - settings->main = console_mode; > + settings->main = console_mode; > + return 0; > } > #endif /* WINDOWSNT */ > + return isatty (fd) - 1; Do we need this "-1" part now? It could misfire if isatty does return 1 some day.