GNU bug report logs - #12881
Assume at least POSIX.1-1988 for fcntl.h

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12881 in the body.
You can then email your comments to 12881 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: bug-gnu-emacs <at> gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>
Subject: Assume at least POSIX.1-1988 for fcntl.h
Date: Tue, 13 Nov 2012 23:37:58 -0800

[Message part 1 (text/plain, inline)]

Tags: patch

On POSIXish hosts it's long been safe to assume at least
POSIX.1-1988, as the pre-POSIX platforms died out long ago.
Attached is a patch to simplify Emacs to assume this
for <fcntl.h>.  I haven't tested this on Windows but have
tried to make the Windows port work by renaming its O_NDELAY
flag to O_NONBLOCK, as POSIX standardized the spelling of this
flag to be O_NONBLOCK.  I'll CC: this patch to Eli to give
him a heads-up.  This patch is relative to trunk bzr 110892.

[fcntl.txt (text/plain, attachment)]

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: Assume at least POSIX.1-1988 for fcntl.h
Date: Wed, 14 Nov 2012 19:33:45 +0200

> Date: Tue, 13 Nov 2012 23:37:58 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: Eli Zaretskii <eliz <at> gnu.org>
> 
> On POSIXish hosts it's long been safe to assume at least
> POSIX.1-1988, as the pre-POSIX platforms died out long ago.
> Attached is a patch to simplify Emacs to assume this
> for <fcntl.h>.  I haven't tested this on Windows but have
> tried to make the Windows port work by renaming its O_NDELAY
> flag to O_NONBLOCK, as POSIX standardized the spelling of this
> flag to be O_NONBLOCK.  I'll CC: this patch to Eli to give
> him a heads-up.  This patch is relative to trunk bzr 110892.

Renaming O_NDELAY is a no-brainer, but the patch does much more than
just that.  In several places, it actually changes the code involved
in dealing with the related issues.  Here's one example:

> @@ -4847,23 +4795,8 @@
>  	      else if (nread == -1 && errno == EWOULDBLOCK)
>  		;
>  #endif
> -	      /* ISC 4.1 defines both EWOULDBLOCK and O_NONBLOCK,
> -		 and Emacs uses O_NONBLOCK, so what we get is EAGAIN.  */
> -#if O_NONBLOCK
> -	      else if (nread == -1 && errno == EAGAIN)
> -		;
> -#else
> -#if O_NDELAY
> -	      else if (nread == -1 && errno == EAGAIN)
> -		;
> -	      /* Note that we cannot distinguish between no input
> -		 available now and a closed pipe.
> -		 With luck, a closed pipe will be accompanied by
> -		 subprocess termination and SIGCHLD.  */
> -	      else if (nread == 0 && !NETCONN_P (proc) && !SERIALCONN_P (proc))
> -		;
> -#endif /* O_NDELAY */
> -#endif /* O_NONBLOCK */
> +	      else if (nread == -1 && errno == EAGAIN)
> +		;

Here, the code that was left is identical to the one used by platforms
with O_NONBLOCK, but the code used by platforms with O_NDELAY was
different in non-trivial ways.

Another potential problem is that the Windows emulation of fcntl only
works for sockets, whereas O_NONBLOCK is now used in other system
calls, like in emacs_open etc.

This patch also modifies code unrelated to O_NONBLOCK, like this one:

> --- src/callproc.c	2012-11-14 04:55:41 +0000
> +++ src/callproc.c	2012-11-14 07:26:25 +0000
> @@ -1317,16 +1317,7 @@
>      return fd;
>    else
>      {
> -      int new;
> -#ifdef F_DUPFD
> -      new = fcntl (fd, F_DUPFD, minfd);
> -#else
> -      new = dup (fd);
> -      if (new != -1)
> -	/* Note that we hold the original FD open while we recurse,
> -	   to guarantee we'll get a new FD if we need it.  */
> -	new = relocate_fd (new, minfd);
> -#endif
> +      int new = fcntl (fd, F_DUPFD, minfd);
>        if (new == -1)
>  	{
>  	  const char *message_1 = "Error while setting up child: ";

Likewise with O_NOCTTY.

It's possible that you've already analyzed all these places, and they
either aren't getting compiled on Windows or are no-ops.  If so,
please tell the details.  Failing that, Someone(TM) will have to do
the footwork of making sure these changes don't break non-Posix
platforms.

Message #11 received at 12881 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 12881 <at> debbugs.gnu.org
Subject: Re: Assume at least POSIX.1-1988 for fcntl.h
Date: Wed, 14 Nov 2012 22:32:07 -0800

[Message part 1 (text/plain, inline)]

On 11/14/2012 09:33 AM, Eli Zaretskii wrote:

> In several places, it actually changes the code involved
> in dealing with the related issues.  Here's one example:

As far as I know, that is the only example involving O_NONBLOCK.

> Here, the code that was left is identical to the one used by platforms
> with O_NONBLOCK, but the code used by platforms with O_NDELAY was
> different in non-trivial ways.

Do those differences matter for Microsoft platforms?  If so, it's
simple to keep them just for DOS_NT, with the following further change:

=== modified file 'src/process.c'
--- src/process.c	2012-11-14 07:26:25 +0000
+++ src/process.c	2012-11-15 06:19:46 +0000
@@ -4797,6 +4797,14 @@
 #endif
 	      else if (nread == -1 && errno == EAGAIN)
 		;
+#ifdef DOS_NT
+	      /* Note that we cannot distinguish between no input
+		 available now and a closed pipe.
+		 With luck, a closed pipe will be accompanied by
+		 subprocess termination and SIGCHLD.  */
+	      else if (nread == 0 && !NETCONN_P (proc) && !SERIALCONN_P (proc))
+		;
+#endif
 #ifdef HAVE_PTYS
 	      /* On some OSs with ptys, when the process on one end of
 		 a pty exits, the other end gets an error reading with


> Another potential problem is that the Windows emulation of fcntl only
> works for sockets, whereas O_NONBLOCK is now used in other system
> calls, like in emacs_open etc.

emacs_open is the only other system call where it's used, and there it's
used only in code that is "#ifndef DOS_NT", so it should be OK.

> This patch also modifies code unrelated to O_NONBLOCK, like this one:

That's OK, as this patch is about all symbols defined by fcntl.h
in POSIX.1-1988, not just about O_NONBLOCK.

> Failing that, Someone(TM) will have to do the footwork of making
> sure these changes don't break non-Posix platforms.

The only non-POSIX platform are the Microsoft ones, right?
And if the above analysis is right, we should be OK.

Attached is a revised patch, relative to trunk bzr 110904,
and with the above extra change.

[fcntl.txt (text/plain, attachment)]

Message #14 received at 12881 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 12881 <at> debbugs.gnu.org
Subject: Re: Assume at least POSIX.1-1988 for fcntl.h
Date: Thu, 15 Nov 2012 19:42:51 +0200

> Date: Wed, 14 Nov 2012 22:32:07 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: 12881 <at> debbugs.gnu.org
> 
> > In several places, it actually changes the code involved
> > in dealing with the related issues.  Here's one example:
> 
> As far as I know, that is the only example involving O_NONBLOCK.
> 
> > Here, the code that was left is identical to the one used by platforms
> > with O_NONBLOCK, but the code used by platforms with O_NDELAY was
> > different in non-trivial ways.
> 
> Do those differences matter for Microsoft platforms?

I don't know, I will have to take a closer look.

> > Another potential problem is that the Windows emulation of fcntl only
> > works for sockets, whereas O_NONBLOCK is now used in other system
> > calls, like in emacs_open etc.
> 
> emacs_open is the only other system call where it's used, and there it's
> used only in code that is "#ifndef DOS_NT", so it should be OK.
> 
> > This patch also modifies code unrelated to O_NONBLOCK, like this one:
> 
> That's OK, as this patch is about all symbols defined by fcntl.h
> in POSIX.1-1988, not just about O_NONBLOCK.

Then perhaps the problem is much smaller than I thought.

> Attached is a revised patch, relative to trunk bzr 110904,
> and with the above extra change.

Thanks, please hold on to it for a few days, until I or someone else
will have time to study it more closely.

Message #17 received at 12881 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 12881 <at> debbugs.gnu.org
Subject: Re: Assume at least POSIX.1-1988 for fcntl.h
Date: Thu, 15 Nov 2012 12:07:37 -0800

On 11/15/12 09:42, Eli Zaretskii wrote:
> Thanks, please hold on to it for a few days, until I or someone else
> will have time to study it more closely.

I'll hold onto it for a bit, but there's no need for a close review
process here.  The code works fine on POSIXish hosts and we've done a
quick scan for plausible failures on Windows hosts and have come up
dry.  Any problems that come up on Windows will likely be either
easy-to-fix compilation issues, or further simplifications of the code
that will not fix bugs.

Message #20 received at 12881 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 12881 <at> debbugs.gnu.org
Cc: Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: Assume at least POSIX.1-1988 for fcntl.h
Date: Thu, 15 Nov 2012 20:38:15 -0800

[Message part 1 (text/plain, inline)]

Come to think of it, there's one more simplification:
remove the test for <fcntl.h> and the use of HAVE_FCNTL_H.
This should be safe since several modules already include <fcntl.h>
unconditionally.  Here's a patch, and I'll attach
a combined patch relative to trunk bzr 110908.

=== modified file 'ChangeLog'
--- ChangeLog	2012-11-16 01:35:18 +0000
+++ ChangeLog	2012-11-16 01:43:28 +0000
@@ -1,6 +1,7 @@
 2012-11-16  Paul Eggert  <eggert <at> cs.ucla.edu>
 
 	Assume POSIX 1003.1-1988 or later for fcntl.h (Bug#12881).
+	* configure.ac: Do not check for fcntl.h.
 	* lib/gnulib.mk: Regenerate.
 
 2012-11-14  Paul Eggert  <eggert <at> cs.ucla.edu>

=== modified file 'admin/CPP-DEFINES'
--- admin/CPP-DEFINES	2012-11-14 07:26:25 +0000
+++ admin/CPP-DEFINES	2012-11-16 04:33:15 +0000
@@ -150,7 +150,6 @@
 HAVE_ENDPWENT
 HAVE_ENVIRON_DECL
 HAVE_EUIDACCESS
-HAVE_FCNTL_H
 HAVE_FORK
 HAVE_FPATHCONF
 HAVE_FREEIFADDRS

=== modified file 'admin/ChangeLog'
--- admin/ChangeLog	2012-11-16 01:35:18 +0000
+++ admin/ChangeLog	2012-11-16 04:33:27 +0000
@@ -1,7 +1,7 @@
 2012-11-16  Paul Eggert  <eggert <at> cs.ucla.edu>
 
 	Assume POSIX 1003.1-1988 or later for fcntl.h (Bug#12881).
-	* CPP-DEFINES (O_RDONLY, O_RDWR): Remove.
+	* CPP-DEFINES (O_RDONLY, O_RDWR, HAVE_FCNTL_H): Remove.
 	* merge-gnulib (GNULIB_MODULES): Add fcntl-h.
 
 2012-11-14  Paul Eggert  <eggert <at> cs.ucla.edu>

=== modified file 'configure.ac'
--- configure.ac	2012-11-14 04:55:41 +0000
+++ configure.ac	2012-11-16 01:39:47 +0000
@@ -1268,7 +1268,7 @@
 dnl checks for header files
 AC_CHECK_HEADERS_ONCE(
   linux/version.h sys/systeminfo.h
-  fcntl.h coff.h pty.h
+  coff.h pty.h
   sys/vlimit.h sys/resource.h
   sys/utsname.h pwd.h utmp.h dirent.h util.h)
 

=== modified file 'lib-src/ChangeLog'
--- lib-src/ChangeLog	2012-10-26 07:40:51 +0000
+++ lib-src/ChangeLog	2012-11-16 01:44:21 +0000
@@ -1,3 +1,8 @@
+2012-11-16  Paul Eggert  <eggert <at> cs.ucla.edu>
+
+	Assume POSIX 1003.1-1988 or later for fcntl.h (Bug#12881).
+	* movemail.c, update-game-score.c: Assume <fcntl.h> exists.
+
 2012-10-26  Glenn Morris  <rgm <at> gnu.org>
 
 	* Makefile.in (uninstall): No INSTALLABLES live in archlibdir.

=== modified file 'lib-src/movemail.c'
--- lib-src/movemail.c	2012-08-10 07:07:07 +0000
+++ lib-src/movemail.c	2012-11-16 01:38:58 +0000
@@ -65,9 +65,7 @@
 
 #include <getopt.h>
 #include <unistd.h>
-#ifdef HAVE_FCNTL_H
 #include <fcntl.h>
-#endif
 #include <string.h>
 #include "syswait.h"
 #ifdef MAIL_USE_POP

=== modified file 'lib-src/update-game-score.c'
--- lib-src/update-game-score.c	2012-07-11 05:44:06 +0000
+++ lib-src/update-game-score.c	2012-11-16 01:39:03 +0000
@@ -42,9 +42,7 @@
 #include <time.h>
 #include <pwd.h>
 #include <ctype.h>
-#ifdef HAVE_FCNTL_H
 #include <fcntl.h>
-#endif
 #include <sys/stat.h>
 #include <getopt.h>
 

=== modified file 'src/ChangeLog'
--- src/ChangeLog	2012-11-16 01:35:18 +0000
+++ src/ChangeLog	2012-11-16 01:44:43 +0000
@@ -5,6 +5,7 @@
 	* emacs.c, term.c (O_RDWR): Remove.
 	* keyboard.c (tty_read_avail_input): Use O_NONBLOCK rather than
 	O_NDELAY, since O_NONBLOCK is the standard name for this flag.
+	* nsterm.m: Assume <fcntl.h> exists.
 	* process.c (NON_BLOCKING_CONNECT, allocate_pty, create_process)
 	(create_pty, Fmake_network_process, server_accept_connection)
 	(wait_reading_process_output, init_process_emacs):

=== modified file 'src/nsterm.m'
--- src/nsterm.m	2012-11-14 04:55:41 +0000
+++ src/nsterm.m	2012-11-16 01:39:22 +0000
@@ -30,6 +30,7 @@
    interpretation of even the system includes. */
 #include <config.h>
 
+#include <fcntl.h>
 #include <math.h>
 #include <sys/types.h>
 #include <time.h>
@@ -40,10 +41,6 @@
 #include <c-strcase.h>
 #include <ftoastr.h>
 
-#ifdef HAVE_FCNTL_H
-#include <fcntl.h>
-#endif
-
 #include "lisp.h"
 #include "blockinput.h"
 #include "sysselect.h"

[fcntl.txt.gz (application/x-gzip, attachment)]

Message #23 received at 12881 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 12881 <at> debbugs.gnu.org
Subject: Re: Assume at least POSIX.1-1988 for fcntl.h
Date: Fri, 16 Nov 2012 11:49:51 +0200

> Date: Thu, 15 Nov 2012 12:07:37 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: 12881 <at> debbugs.gnu.org
> 
> On 11/15/12 09:42, Eli Zaretskii wrote:
> > Thanks, please hold on to it for a few days, until I or someone else
> > will have time to study it more closely.
> 
> I'll hold onto it for a bit, but there's no need for a close review
> process here.  The code works fine on POSIXish hosts and we've done a
> quick scan for plausible failures on Windows hosts and have come up
> dry.  Any problems that come up on Windows will likely be either
> easy-to-fix compilation issues, or further simplifications of the code
> that will not fix bugs.

Thanks for waiting.

The reason I prefer to review the patches such as this one is to
minimize downtime for several Windows users who track the development
trunk.  As you see below, our initial discussion notwithstanding, your
patches still break the Windows build in several places.  Experience
shows that if the Windows build is broken, it remains broken until I
get to fix it, with no one else stepping forward to do that.  It is
IMO bad mojo for several good people to depend on my scarce free time
or sleeping hours.

Here's the result of reviewing the combined patch you've posted in
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12881#20:

  @@ -4847,23 +4795,16 @@
		else if (nread == -1 && errno == EWOULDBLOCK)
		  ;
   #endif
  -	      /* ISC 4.1 defines both EWOULDBLOCK and O_NONBLOCK,
  -		 and Emacs uses O_NONBLOCK, so what we get is EAGAIN.  */
  -#if O_NONBLOCK
  -	      else if (nread == -1 && errno == EAGAIN)
  -		;
  -#else
  -#if O_NDELAY
  -	      else if (nread == -1 && errno == EAGAIN)
  -		;
  +	      else if (nread == -1 && errno == EAGAIN)
  +		;
  +#ifdef DOS_NT
		/* Note that we cannot distinguish between no input
		   available now and a closed pipe.
		   With luck, a closed pipe will be accompanied by
		   subprocess termination and SIGCHLD.  */
		else if (nread == 0 && !NETCONN_P (proc) && !SERIALCONN_P (proc))
		  ;
  -#endif /* O_NDELAY */
  -#endif /* O_NONBLOCK */
  +#endif

This hunk from process.c patches should use WINDOWSNT, not DOS_NT,
since MSDOS does not compile that part of process.c.

  @@ -1278,8 +1276,7 @@
     fsync (fileno (tty_out->output));
   #endif

  -#ifdef F_SETFL
  -#ifdef F_SETOWN		/* F_SETFL does not imply existence of F_SETOWN */
  +#ifdef F_SETOWN
     if (interrupt_input)
       {
	 reset_sigio (fileno (tty_out->input));
  @@ -1287,11 +1284,8 @@
		old_fcntl_owner[fileno (tty_out->input)]);
       }
   #endif /* F_SETOWN */
  -#if O_NDELAY
     fcntl (fileno (tty_out->input), F_SETFL,
  -         fcntl (fileno (tty_out->input), F_GETFL, 0) & ~O_NDELAY);
  -#endif
  -#endif /* F_SETFL */
  +         fcntl (fileno (tty_out->input), F_GETFL, 0) & ~O_NONBLOCK);

     if (tty_out->old_tty)
       while (emacs_set_tty (fileno (tty_out->input),

In this hunk, the block that was conditioned on F_SETFL should now be
conditioned on !DOS_NT.  The reason is that, although the Windows
build does have F_SETFL defined, it is defined in sys/socket.h, which
is not included by sysdep.c in the MS-Windows build.  So this block of
code was never compiled on Windows, and should continue not being
compiled there, since it invokes fcntl on TTY handles, something
that's not supported by w32.c:fcntl emulation, and also uses F_GETFL
which is not defined on Windows.

  --- src/term.c	2012-11-14 04:55:41 +0000
  +++ src/term.c	2012-11-14 07:26:25 +0000
  @@ -55,14 +55,6 @@
   #include "xterm.h"
   #endif

  -#ifndef O_RDWR
  -#define O_RDWR 2
  -#endif
  -
  -#ifndef O_NOCTTY
  -#define O_NOCTTY 0
  -#endif
  -
   /* The name of the default console device.  */
   #ifdef WINDOWSNT

This hunk will break MS-Windows compilation because O_NOCTTY is no
longer defined.  I suggest adding the definition in the WINDOWSNT
block just below, where the default console device name is defined.

Also, you need to include fcntl.h in term.c, to get both O_RDRW and
O_NOCTTY actually defined.  I wonder how it compiled for you;
presumably some other header on your platform includes fcntl.h
internally, but we shouldn't depend on that, IMO.

With those changes, I think the patch is safe to go into the trunk.
Thanks.

Message #26 received at 12881 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 12881 <at> debbugs.gnu.org
Subject: Re: bug#12881: Assume at least POSIX.1-1988 for fcntl.h
Date: Fri, 16 Nov 2012 09:37:06 -0500

> The reason I prefer to review the patches such as this one is to
> minimize downtime for several Windows users who track the
> development trunk.

Actually, they should track `emacs-24' nowadays anyway ;-)


        Stefan

Message #29 received at 12881 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>,
	12881 <at> debbugs.gnu.org
Subject: Re: bug#12881: Assume at least POSIX.1-1988 for fcntl.h
Date: Fri, 16 Nov 2012 15:55:13 +0100

On Fri, Nov 16, 2012 at 3:37 PM, Stefan Monnier
<monnier <at> iro.umontreal.ca> wrote:

> Actually, they should track `emacs-24' nowadays anyway ;-)

At least one of them it is doing it now... ;-)

But as for Eli's comment, he's quite right in saying that, when things
break, he's the only one to fix them. Many of the recent changes that
have broken Windows need to be fixed by someone who's not only
well-versed on Windows development, but also POSIX. Unfortunately the
number of people with that skill set is tiny among Emacs developers, I
think.

    Juanma

Message #32 received at 12881 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>,
	12881 <at> debbugs.gnu.org
Subject: Re: bug#12881: Assume at least POSIX.1-1988 for fcntl.h
Date: Fri, 16 Nov 2012 10:26:11 -0500

> But as for Eli's comment, he's quite right in saying that, when things
> break, he's the only one to fix them.  Many of the recent changes that
> have broken Windows need to be fixed by someone who's not only
> well-versed on Windows development, but also POSIX.  Unfortunately the
> number of people with that skill set is tiny among Emacs developers,
> I think.

Yes, indeed.  I find it a bit scary, actually,


        Stefan

Message #35 received at 12881 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: lekktu <at> gmail.com, eggert <at> cs.ucla.edu, 12881 <at> debbugs.gnu.org
Subject: Re: bug#12881: Assume at least POSIX.1-1988 for fcntl.h
Date: Fri, 16 Nov 2012 18:00:44 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  Paul Eggert <eggert <at> cs.ucla.edu>,  12881 <at> debbugs.gnu.org
> Date: Fri, 16 Nov 2012 10:26:11 -0500
> 
> > But as for Eli's comment, he's quite right in saying that, when things
> > break, he's the only one to fix them.  Many of the recent changes that
> > have broken Windows need to be fixed by someone who's not only
> > well-versed on Windows development, but also POSIX.  Unfortunately the
> > number of people with that skill set is tiny among Emacs developers,
> > I think.
> 
> Yes, indeed.  I find it a bit scary, actually,

It's not.  It involves careful reading of the code and of the Posix
spec, that's all.

Message #38 received at 12881 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: eggert <at> cs.ucla.edu, Stefan Monnier <monnier <at> iro.umontreal.ca>,
	12881 <at> debbugs.gnu.org
Subject: Re: bug#12881: Assume at least POSIX.1-1988 for fcntl.h
Date: Fri, 16 Nov 2012 17:29:30 +0100

On Fri, Nov 16, 2012 at 5:00 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:

> It's not.  It involves careful reading of the code and of the Posix
> spec, that's all.

Well, perhaps. But watching the back-and-forth between Paul and you,
it seems to me that things aren't so straightforward. A "careful
reading" of such a snake pit doesn't seem to me to be that far from my
"well versed" description.

    Juanma

Message #41 received at 12881 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: lekktu <at> gmail.com, eggert <at> cs.ucla.edu, 12881 <at> debbugs.gnu.org
Subject: Re: bug#12881: Assume at least POSIX.1-1988 for fcntl.h
Date: Fri, 16 Nov 2012 12:10:11 -0500

>> > But as for Eli's comment, he's quite right in saying that, when things
>> > break, he's the only one to fix them.  Many of the recent changes that
>> > have broken Windows need to be fixed by someone who's not only
>> > well-versed on Windows development, but also POSIX.  Unfortunately the
>> > number of people with that skill set is tiny among Emacs developers,
>> > I think.
>> Yes, indeed.  I find it a bit scary, actually,
> It's not.

I'm not sure we're talking about the same thing.  What scares me is the
"what would happen without Eli?".


        Stefan

Message #44 received at 12881 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, eggert <at> cs.ucla.edu, 12881 <at> debbugs.gnu.org
Subject: Re: bug#12881: Assume at least POSIX.1-1988 for fcntl.h
Date: Fri, 16 Nov 2012 18:14:54 +0100

On Fri, Nov 16, 2012 at 6:10 PM, Stefan Monnier
<monnier <at> iro.umontreal.ca> wrote:

> What scares me is the "what would happen without Eli?".

+1

    Juanma

Message #47 received at 12881 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, eggert <at> cs.ucla.edu, 12881 <at> debbugs.gnu.org
Subject: Re: bug#12881: Assume at least POSIX.1-1988 for fcntl.h
Date: Fri, 16 Nov 2012 18:20:27 +0100

> On Fri, Nov 16, 2012 at 6:10 PM, Stefan Monnier

> What scares me is the "what would happen without Eli?".

Aside: the first thing that would happen (in about five minutes, ten
tops) is that someone would commit a change removing the MS-DOS
support and renaming a bunch of files to use long names...

(Sorry, couldn't resist)

    Juanma

Message #50 received at 12881 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: eggert <at> cs.ucla.edu, monnier <at> iro.umontreal.ca, 12881 <at> debbugs.gnu.org
Subject: Re: bug#12881: Assume at least POSIX.1-1988 for fcntl.h
Date: Fri, 16 Nov 2012 19:41:20 +0200

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Fri, 16 Nov 2012 17:29:30 +0100
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, eggert <at> cs.ucla.edu, 12881 <at> debbugs.gnu.org
> 
> On Fri, Nov 16, 2012 at 5:00 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> > It's not.  It involves careful reading of the code and of the Posix
> > spec, that's all.
> 
> Well, perhaps. But watching the back-and-forth between Paul and you,
> it seems to me that things aren't so straightforward.

Most of that is just differences of opinions and styles, actually.
The factual basis is more or less known, solid, and not subject to
dispute.

Message #53 received at 12881 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: lekktu <at> gmail.com, eggert <at> cs.ucla.edu, 12881 <at> debbugs.gnu.org
Subject: Re: bug#12881: Assume at least POSIX.1-1988 for fcntl.h
Date: Fri, 16 Nov 2012 19:44:40 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: lekktu <at> gmail.com,  eggert <at> cs.ucla.edu,  12881 <at> debbugs.gnu.org
> Date: Fri, 16 Nov 2012 12:10:11 -0500
> 
> >> > But as for Eli's comment, he's quite right in saying that, when things
> >> > break, he's the only one to fix them.  Many of the recent changes that
> >> > have broken Windows need to be fixed by someone who's not only
> >> > well-versed on Windows development, but also POSIX.  Unfortunately the
> >> > number of people with that skill set is tiny among Emacs developers,
> >> > I think.
> >> Yes, indeed.  I find it a bit scary, actually,
> > It's not.
> 
> I'm not sure we're talking about the same thing.  What scares me is the
> "what would happen without Eli?".

That scares me as well.

Message #56 received at 12881 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>,
	"'Stefan Monnier'" <monnier <at> iro.umontreal.ca>
Cc: 'Juanma Barranquero' <lekktu <at> gmail.com>, eggert <at> cs.ucla.edu,
	12881 <at> debbugs.gnu.org
Subject: RE: bug#12881: Assume at least POSIX.1-1988 for fcntl.h
Date: Fri, 16 Nov 2012 09:52:25 -0800

> > >> Yes, indeed.  I find it a bit scary, actually,
> > > It's not.
> > 
> > I'm not sure we're talking about the same thing.  What 
> > scares me is the "what would happen without Eli?".
> That scares me as well.

I wasn't going to say anything, but I realized what Stefan meant and was
thinking the same thing (+1).  And not just for the resulting loss of Windows
knowledge/support, obviously.  Knock on wood.

Message #61 received at 12881-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 12881-done <at> debbugs.gnu.org
Subject: Re: Assume at least POSIX.1-1988 for fcntl.h
Date: Sat, 17 Nov 2012 14:17:14 -0800

On 11/16/2012 01:49 AM, Eli Zaretskii wrote:
> I wonder how it compiled for you;
> presumably some other header on your platform includes fcntl.h
> internally

It's systty.h, which includes fcntl.h everywhere.
But it doesn't hurt to include it again, so I did that.
I took the other suggestions you made as well, except
that I moved the replacement definitions of O_RDWR and
O_NOCTTY into nt/inc/unistd.h rather than to some other
spot in term.c.  It's cleaner to define system macros
in our implementation of the system rather than in the
application.  In the longer run we may want to move those
macros to a new file that replaces fcntl.h, but that's
for another day.

I installed this as trunk bzr 110931 and am marking it as
done.

Message #64 received at 12881 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 12881 <at> debbugs.gnu.org
Subject: Re: Assume at least POSIX.1-1988 for fcntl.h
Date: Sun, 18 Nov 2012 05:46:02 +0200

> Date: Sat, 17 Nov 2012 14:17:14 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: 12881-done <at> debbugs.gnu.org
> 
> I moved the replacement definitions of O_RDWR and
> O_NOCTTY into nt/inc/unistd.h rather than to some other
> spot in term.c.

I wish you'd discuss this first.  O_RDWR doesn't need to be defined
(it is already defined by a Windows system header), and defining
O_NOCTTY in a header included by many sources is wrong, because it
triggers compilation of other non-Windows friendly code elsewhere.

Looks like I invested all that effort in vain, and the Windows build
will be broken anyway.  Sigh.

Message #67 received at 12881 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 12881 <at> debbugs.gnu.org
Subject: Re: Assume at least POSIX.1-1988 for fcntl.h
Date: Sat, 17 Nov 2012 20:41:24 -0800

On 11/17/2012 07:46 PM, Eli Zaretskii wrote:
> O_RDWR doesn't need to be defined
> (it is already defined by a Windows system header)

OK, sorry, I misunderstood your earlier recommendation (to move
O_NOCTTY) to also refer to O_RDWR.  If you like, I can easily
remove the unnecessary definition of O_RDWR in nt/inc/unistd.h.

> defining O_NOCTTY in a header included by many sources is wrong, because it
> triggers compilation of other non-Windows friendly code elsewhere.
  
No, there's no "#ifdef O_NOCTTY" or "#if ... defined O_NOCTTY ..."
anywhere in Emacs that would be affected by this definition.
The non-Microsoft code already falls back on "#define O_NOCTTY 0"
for platforms that lack O_NOCTTY, and the Microsoft code can
safely do the same.

> Looks like I invested all that effort in vain

I don't see why here, either.  Neither of these appear to be problems
that would break a build or cause Emacs to misbehave.  And even if they
were, any fixes would be trivial.

Message #70 received at 12881 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 12881 <at> debbugs.gnu.org
Subject: Re: Assume at least POSIX.1-1988 for fcntl.h
Date: Sun, 18 Nov 2012 18:58:45 +0200

> Date: Sat, 17 Nov 2012 20:41:24 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: 12881 <at> debbugs.gnu.org
> 
> On 11/17/2012 07:46 PM, Eli Zaretskii wrote:
> > O_RDWR doesn't need to be defined
> > (it is already defined by a Windows system header)
> 
> OK, sorry, I misunderstood your earlier recommendation (to move
> O_NOCTTY) to also refer to O_RDWR.  If you like, I can easily
> remove the unnecessary definition of O_RDWR in nt/inc/unistd.h.

Thanks, I already did that.

> > Looks like I invested all that effort in vain
> 
> I don't see why here, either.  Neither of these appear to be problems
> that would break a build or cause Emacs to misbehave.  And even if they
> were, any fixes would be trivial.

I tried for once to make this commit clean, not requiring any fixes at
all.  I hope in the future, if you decide to do things that affect the
w32 build differently than what I suggest, we could discuss this
first, especially if I already invested some effort into making the
changes as clean as possible for Windows.  TIA.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.