[PATCHES] 21.3.50 for Cygwin: patch 5

[PATCHES] 21.3.50 for Cygwin: patch 5

[Joe Buehler]

This patch fixes various C code issues for Cygwin.  Note that the
diff at the end is the new src/s/cygwin.h file.

Joe Buehler

Index: ./lib-src/ChangeLog
===================================================================
RCS file: /cvsroot/emacs/emacs/lib-src/ChangeLog,v
retrieving revision 2.212
diff -u -r2.212 ChangeLog
--- ./lib-src/ChangeLog	4 Dec 2002 11:19:42 -0000	2.212
+++ ./lib-src/ChangeLog	6 Dec 2002 17:38:39 -0000
@@ -1,3 +1,7 @@
+2002-12-06  Joe Buehler  <jhpb@draco.hekimian.com>
+
+	* pop.c: a Cygwin header file defines _P, so undef it
+
  2002-12-04  Richard M. Stallman  <rms@gnu.org>

  	* Update getopt from gnulib version; changes described below.
Index: ./src/ChangeLog
===================================================================
RCS file: /cvsroot/emacs/emacs/src/ChangeLog,v
retrieving revision 1.2979
diff -u -r1.2979 ChangeLog
--- ./src/ChangeLog	4 Dec 2002 11:44:42 -0000	1.2979
+++ ./src/ChangeLog	6 Dec 2002 17:39:00 -0000
@@ -1,3 +1,7 @@
+2002-12-06  Joe Buehler  <jhpb@draco.hekimian.com>
+
+	* s/cygwin.h: added for Cygwin port
+
  2002-12-04  Richard M. Stallman  <rms@gnu.org>

  	* sysdep.c (fcntl.h): Test only HAVE_FCNTL_H.
Index: ./src/ChangeLog
===================================================================
RCS file: /cvsroot/emacs/emacs/src/ChangeLog,v
retrieving revision 1.2979
diff -u -r1.2979 ChangeLog
--- ./src/ChangeLog	4 Dec 2002 11:44:42 -0000	1.2979
+++ ./src/ChangeLog	6 Dec 2002 17:39:00 -0000
@@ -1,3 +1,11 @@
+2002-12-06  Joe Buehler  <jhpb@draco.hekimian.com>
+
+	* mem-limits.h: added ifdef to define BSD4_2 for Cygwin
+
+	* keyboard.c: port to Cygwin (just added proper preprocessor tests)
+
+	* fileio.c: support // at start of name for Cygwin (just added proper preprocessor tests)
+
  2002-12-04  Richard M. Stallman  <rms@gnu.org>

  	* sysdep.c (fcntl.h): Test only HAVE_FCNTL_H.
Index: lib-src/pop.c
===================================================================
RCS file: /cvsroot/emacs/emacs/lib-src/pop.c,v
retrieving revision 1.31
diff -u -r1.31 pop.c
--- lib-src/pop.c	17 May 2002 11:24:02 -0000	1.31
+++ lib-src/pop.c	6 Dec 2002 16:34:43 -0000
@@ -119,6 +119,9 @@
  #endif
  #endif

+#ifdef _P
+#undef _P
+#endif
  #ifndef _P
  # ifdef __STDC__
  #  define _P(a) a
cvs server: Diffing lisp
Index: src/fileio.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/fileio.c,v
retrieving revision 1.466
diff -u -r1.466 fileio.c
--- src/fileio.c	4 Dec 2002 11:44:00 -0000	1.466
+++ src/fileio.c	6 Dec 2002 16:35:27 -0000
@@ -2052,13 +2052,13 @@
    for (p = nm; p != endp; p++)
      {
        if ((p[0] == '~'
-#if defined (APOLLO) || defined (WINDOWSNT)
-	   /* // at start of file name is meaningful in Apollo and
-	      WindowsNT systems.  */
+#if defined (APOLLO) || defined (WINDOWSNT) || defined(CYGWIN)
+	   /* // at start of file name is meaningful in Apollo,
+	      WindowsNT and Cygwin systems.  */
  	   || (IS_DIRECTORY_SEP (p[0]) && p - 1 != nm)
-#else /* not (APOLLO || WINDOWSNT) */
+#else /* not (APOLLO || WINDOWSNT || CYGWIN) */
  	   || IS_DIRECTORY_SEP (p[0])
-#endif /* not (APOLLO || WINDOWSNT) */
+#endif /* not (APOLLO || WINDOWSNT || CYGWIN) */
  	   )
  	  && p != nm
  	  && (0
@@ -2230,11 +2230,11 @@

    for (p = xnm; p != x; p++)
      if ((p[0] == '~'
-#if defined (APOLLO) || defined (WINDOWSNT)
+#if defined (APOLLO) || defined (WINDOWSNT) || defined(CYGWIN)
  	 || (IS_DIRECTORY_SEP (p[0]) && p - 1 != xnm)
-#else /* not (APOLLO || WINDOWSNT) */
+#else /* not (APOLLO || WINDOWSNT || CYGWIN) */
  	 || IS_DIRECTORY_SEP (p[0])
-#endif /* not (APOLLO || WINDOWSNT) */
+#endif /* not (APOLLO || WINDOWSNT || CYGWIN) */
  	 )
  	&& p != xnm && IS_DIRECTORY_SEP (p[-1]))
        xnm = p;
Index: src/keyboard.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/keyboard.c,v
retrieving revision 1.716
diff -u -r1.716 keyboard.c
--- src/keyboard.c	22 Nov 2002 12:23:13 -0000	1.716
+++ src/keyboard.c	6 Dec 2002 16:35:33 -0000
@@ -6492,7 +6492,7 @@
        if (n_to_read > sizeof cbuf)
  	n_to_read = sizeof cbuf;
  #else /* no FIONREAD */
-#if defined (USG) || defined (DGUX)
+#if defined (USG) || defined (DGUX) || defined(CYGWIN)
        /* Read some input if available, but don't wait.  */
        n_to_read = sizeof cbuf;
        fcntl (input_fd, F_SETFL, O_NDELAY);
@@ -6549,9 +6549,9 @@
  	     );

  #ifndef FIONREAD
-#if defined (USG) || defined (DGUX)
+#if defined (USG) || defined (DGUX) || defined (CYGWIN)
        fcntl (input_fd, F_SETFL, 0);
-#endif /* USG or DGUX */
+#endif /* USG or DGUX or CYGWIN */
  #endif /* no FIONREAD */
        for (i = 0; i < nread; i++)
  	{
Index: src/mem-limits.h
===================================================================
RCS file: /cvsroot/emacs/emacs/src/mem-limits.h,v
retrieving revision 1.31
diff -u -r1.31 mem-limits.h
--- src/mem-limits.h	19 Aug 2002 17:45:50 -0000	1.31
+++ src/mem-limits.h	6 Dec 2002 16:35:33 -0000
@@ -46,6 +46,10 @@
  #define BSD4_2
  #endif

+#ifdef CYGWIN
+#define BSD4_2
+#endif
+
  #ifndef BSD4_2
  #ifndef USG
  #ifndef MSDOS
--- src/s/cygwin.h	2002-12-06 12:58:52.000000000 -0500
+++ src/s/cygwin.h	2002-12-05 16:47:00.000000000 -0500
@@ -0,0 +1,146 @@
+/* Template for system description header files.
+   This file describes the parameters that system description files
+   should define or not.
+   Copyright (C) 1985, 1986, 1992, 1999 Free Software Foundation, Inc.
+
+This file is part of GNU Emacs.
+
+GNU Emacs is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+GNU Emacs is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU Emacs; see the file COPYING.  If not, write to
+the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+Boston, MA 02111-1307, USA.  */
+
+/* SYSTEM_TYPE should indicate the kind of system you are using.
+ It sets the Lisp variable system-type.  */
+
+#define SYSTEM_TYPE "cygwin"
+
+/* Emacs can read input using SIGIO and buffering characters itself,
+   or using CBREAK mode and making C-g cause SIGINT.
+   The choice is controlled by the variable interrupt_input.
+
+   Define INTERRUPT_INPUT to make interrupt_input = 1 the default (use SIGIO)
+
+   Emacs uses the presence or absence of the SIGIO and BROKEN_SIGIO macros
+   to indicate whether or not signal-driven I/O is possible.  It uses
+   INTERRUPT_INPUT to decide whether to use it by default.
+
+   SIGIO can be used only on systems that implement it (4.2 and 4.3).
+   CBREAK mode has two disadvantages
+     1) At least in 4.2, it is impossible to handle the Meta key properly.
+        I hear that in system V this problem does not exist.
+     2) Control-G causes output to be discarded.
+        I do not know whether this can be fixed in system V.
+
+   Another method of doing input is planned but not implemented.
+   It would have Emacs fork off a separate process
+   to read the input and send it to the true Emacs process
+   through a pipe. */
+
+#undef INTERRUPT_INPUT
+
+/*
+ *	Define HAVE_TERMIOS if the system provides POSIX-style
+ *	functions and macros for terminal control.
+ *
+ *	Define HAVE_TERMIO if the system provides sysV-style ioctls
+ *	for terminal control.
+ *
+ *	Do not define both.  HAVE_TERMIOS is preferred, if it is
+ *	supported on your system.
+ */
+
+#define HAVE_TERMIOS
+
+/*
+ *	Define HAVE_PTYS if the system supports pty devices.
+ */
+
+#define HAVE_PTYS
+#define PTY_ITERATION		for (i = 0; i < 1; i++) /* ick */
+#define PTY_NAME_SPRINTF	/* none */
+#define PTY_TTY_NAME_SPRINTF	/* none */
+#define PTY_OPEN					\
+  do							\
+    {							\
+      int dummy;					\
+      SIGMASKTYPE mask;					\
+      mask = sigblock (sigmask (SIGCHLD));		\
+      if (-1 == openpty (&fd, &dummy, pty_name, 0, 0))	\
+	fd = -1;					\
+      sigsetmask (mask);				\
+      emacs_close (dummy);				\
+    }							\
+  while (0)
+
+/* Define this symbol if your system has the functions bcopy, etc. */
+
+#define BSTRING
+
+/* subprocesses should be defined if you want to
+   have code for asynchronous subprocesses
+   (as used in M-x compile and M-x shell).
+   This is generally OS dependent, and not supported
+   under most USG systems. */
+
+#define subprocesses
+
+/* Define CLASH_DETECTION if you want lock files to be written
+   so that Emacs can tell instantly when you try to modify
+   a file that someone else has modified in his Emacs.  */
+
+#define CLASH_DETECTION
+
+/* If the system's imake configuration file defines `NeedWidePrototypes'
+   as `NO', we must define NARROWPROTO manually.  Such a define is
+   generated in the Makefile generated by `xmkmf'.  If we don't
+   define NARROWPROTO, we will see the wrong function prototypes
+   for X functions taking float or double parameters.  */
+
+#define NARROWPROTO 1
+
+/* used in various places to enable cygwin-specific code changes */
+#define CYGWIN 1
+
+#define PENDING_OUTPUT_COUNT(FILE) ((FILE)->_p - (FILE)->_bf._base)
+#define GETPGRP_NO_ARG 1
+#define SYSV_SYSTEM_DIR 1
+/* -lutil comes from inetutils and has pty functions in it */
+#define LIBS_SYSTEM -lutil
+/* undumping is not implemented yet */
+#define CANNOT_DUMP 1
+#define POSIX_SIGNALS 1
+/* force the emacs image to start high in memory, so dll relocation
+   can put things in low memory without causing all sorts of grief for
+   emacs lisp pointers */
+#define DATA_SEG_BITS 0x20000000
+#define LINKER $(CC) -Wl,--image-base,DATA_SEG_BITS
+/* gettext.h is in a strange place */
+#define C_SWITCH_SYSTEM -I/usr/share/gettext
+
+/* Use terminfo instead of termcap.  Fewer environment variables to
+   go wrong, more terminal types. */
+#define TERMINFO
+
+#define HAVE_SOCKETS
+/* C-g aborts emacs without this */
+/*#define HAVE_VFORK*/
+/* Xaw3d causes problems -- might have been fixed by NARROWPROTO
+   above, but I haven't tried it */
+#undef HAVE_XAW3D
+
+/* vfork() interacts badly with setsid(), causing ptys to fail to
+   change their controlling terminal */
+#define vfork fork
+
+/* the end */

Re: [PATCHES] 21.3.50 for Cygwin: patch 5

[Eli Zaretskii]

On Fri, 6 Dec 2002, Joe Buehler wrote:

> --- lib-src/pop.c	17 May 2002 11:24:02 -0000	1.31
> +++ lib-src/pop.c	6 Dec 2002 16:34:43 -0000
> @@ -119,6 +119,9 @@
>   #endif
>   #endif
> 
> +#ifdef _P
> +#undef _P
> +#endif
>   #ifndef _P
>   # ifdef __STDC__
>   #  define _P(a) a

This might be dangerous: other platforms could define _P in their system 
header, and this patch then causes them to use the definition supplied by 
pop.c.  If that definition somehow doesn't work on some of those 
platforms, pop.c is now broken on them.

In other words, this change has effect much beyond the Cygwin port, and 
should IMHO be avoided if possible.

Why isn't the original #ifndef guard enough to solve the problem on 
Cygwin?  Could you please show how does the original code fail, and 
explain why?

> --- src/mem-limits.h	19 Aug 2002 17:45:50 -0000	1.31
> +++ src/mem-limits.h	6 Dec 2002 16:35:33 -0000
> @@ -46,6 +46,10 @@
>   #define BSD4_2
>   #endif
> 
> +#ifdef CYGWIN
> +#define BSD4_2
> +#endif

Can't this be done in src/s/cygwin.h?

Re: [PATCHES] 21.3.50 for Cygwin: patch 5

[Juanma Barranquero]

On Wed, 25 Dec 2002 08:12:45 +0200 (IST), Eli Zaretskii <eliz@is.elta.co.il> wrote:

> In other words, this change has effect much beyond the Cygwin port, and 
> should IMHO be avoided if possible.

I'd like to have (relatively soon) an answer (from Joe, or whomever it
is approppriate) to this and the other questions you pose. I have an
omnibus-patch ready to install... and it's a bit painful to manually
maintain it against changes in the HEAD.

                                                           /L/e/k/t/u

Re: [PATCHES] 21.3.50 for Cygwin: patch 5

[Richard Stallman]

    > In other words, this change has effect much beyond the Cygwin port, and 
    > should IMHO be avoided if possible.

Precisely which change are we discussing?  I can't remember; it must have
been a week or two ago.

Re: [PATCHES] 21.3.50 for Cygwin: patch 5

[Juanma Barranquero]

On Thu, 26 Dec 2002 18:39:12 -0500, Richard Stallman <rms@gnu.org> wrote:

> Precisely which change are we discussing? 

Eli raised other issues (about using an EXEEXT variable in makefiles,
mostly), but the most serius is with respect to the accompanying patch.

                                                           /L/e/k/t/u


Index: pop.c
===================================================================
RCS file: /cvs/emacs/lib-src/pop.c,v
retrieving revision 1.31
diff -u -2 -r1.31 pop.c
--- pop.c	17 May 2002 11:24:02 -0000	1.31
+++ pop.c	27 Dec 2002 07:42:48 -0000
@@ -120,4 +120,7 @@
 #endif
 
+#ifdef _P
+#undef _P
+#endif
 #ifndef _P
 # ifdef __STDC__

Re: [PATCHES] 21.3.50 for Cygwin: patch 5

[Richard Stallman]

    --- pop.c	17 May 2002 11:24:02 -0000	1.31
    +++ pop.c	27 Dec 2002 07:42:48 -0000
    @@ -120,4 +120,7 @@
     #endif

    +#ifdef _P
    +#undef _P
    +#endif
     #ifndef _P
     # ifdef __STDC__

Is it possible to do something in a Cygwin-only file, or a
Windows-only file, that defines _P the right way before this point?
That would seem to make this change unnecessary and without risk
of breaking other systems.

Re: [PATCHES] 21.3.50 for Cygwin: patch 5

[Joe Buehler]

Eli Zaretskii wrote:

>>+#ifdef _P
>>+#undef _P
>>+#endif
>>  #ifndef _P
>>  # ifdef __STDC__
>>  #  define _P(a) a

> Why isn't the original #ifndef guard enough to solve the problem on 
> Cygwin?  Could you please show how does the original code fail, and 
> explain why?

The problem is that _P is defined in the cygwin header files in a manner
that is incompatible with its usage above.  It is one of a set of macros
used in code that classifies characters as white space, printable, etc.:

ctype.h:#define _P	020
ctype.h:#define ispunct(c)	((_ctype_+1)[(unsigned)(c)]&_P)
ctype.h:#define isprint(c)	((_ctype_+1)[(unsigned)(c)]&(_P|_U|_L|_N|_B))
ctype.h:#define	isgraph(c)	((_ctype_+1)[(unsigned)(c)]&(_P|_U|_L|_N))

The above usage in pop.c does not seem correct to me -- aren't symbols
beginning with _ supposed to be reserved for the compilation system, to avoid
conflicts such as this one?

>>--- src/mem-limits.h	19 Aug 2002 17:45:50 -0000	1.31
>>+++ src/mem-limits.h	6 Dec 2002 16:35:33 -0000
>>@@ -46,6 +46,10 @@
>>  #define BSD4_2
>>  #endif
>>
>>+#ifdef CYGWIN
>>+#define BSD4_2
>>+#endif
> 
> 
> Can't this be done in src/s/cygwin.h?

Setgid on a directory does not cause group inheritance under cygwin,
so the code in dired.c for BSD4_2 is incorrect in that case.  The ifdef
could be moved to dired.c.  I don't like the idea of defining it in
cygwin.h, however, since BSD4_2 has nothing to do with cygwin...
-- 
Joe Buehler

Re: [PATCHES] 21.3.50 for Cygwin: patch 5

[Richard Stallman]

    The above usage in pop.c does not seem correct to me -- aren't symbols
    beginning with _ supposed to be reserved for the compilation system, to avoid
    conflicts such as this one?

Yes, I thyink that is true.  Perhaps we should change Emacs to use P
instead of _P.  But that is a rather large change, albeit not a very
deep one.

Re: [PATCHES] 21.3.50 for Cygwin: patch 5

[Eli Zaretskii]

> Date: Fri, 03 Jan 2003 11:19:15 -0500
> From: Joe Buehler <jbuehler@hekimian.com>
> 
> The problem is that _P is defined in the cygwin header files in a manner
> that is incompatible with its usage above.  It is one of a set of macros
> used in code that classifies characters as white space, printable, etc.:

Ouch!  This IMHO warrants a bug report to Cygwin maintainers.

> The above usage in pop.c does not seem correct to me -- aren't symbols
> beginning with _ supposed to be reserved for the compilation system, to avoid
> conflicts such as this one?

That's true, except that _P is used in many libraries' header files to
allow prototypes in ANSI compilers without breaking non-ANSI ones.

Okay, if this is the case, please make the #undef _P thing conditioned
on Cygwin.  That would at least limit the effect of the change to the
Cygwin build.  I'd also suggest a comment there explaining why is this
done, which mentions the use of _P in ctype.h macros.

Re: [PATCHES] 21.3.50 for Cygwin: patch 5

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     The above usage in pop.c does not seem correct to me -- aren't symbols
>     beginning with _ supposed to be reserved for the compilation system, to avoid
>     conflicts such as this one?
> 
> Yes, I thyink that is true.  Perhaps we should change Emacs to use P
> instead of _P.  But that is a rather large change, albeit not a very
> deep one.

We already use P_ in most cases (under src/), and __P in a few other
cases (mostly under lib-src/ and lwlib/).

So it seems a bit odd that pop.c (as the only file) uses _P.

I suggest we simply change pop.c to use __P like the other files in
lib-src.

Shall I make that change?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: 21.3.50 for Cygwin: patch 5

[Benjamin Riefenstahl]

Pardon me for butting in.

storm@cua.dk (Kim F. Storm) writes:
> We already use P_ in most cases (under src/), and __P in a few other
> cases (mostly under lib-src/ and lwlib/).
> 
> So it seems a bit odd that pop.c (as the only file) uses _P.
> 
> I suggest we simply change pop.c to use __P like the other files in
> lib-src.

Both "__P" and "_P" are both firmly and totally in the compiler domain
(anything matching the regexp /^_[_A-Z]/ is).  Compilers can use these
symbols however they see fit.  "P_" OTOH is free for use in user
programs.  So if a change is needed anyway, it should be to "P_"
(IMO).

so long, benny

Re: [PATCHES] 21.3.50 for Cygwin: patch 5

[Richard Stallman]

    So it seems a bit odd that pop.c (as the only file) uses _P.

    I suggest we simply change pop.c to use __P like the other files in
    lib-src.

Ok, that's a good idea.

    Shall I make that change?

Please do.

Re: 21.3.50 for Cygwin: patch 5

[Kim F. Storm]

Benjamin Riefenstahl <Benjamin.Riefenstahl@epost.de> writes:

> Pardon me for butting in.
> 
> storm@cua.dk (Kim F. Storm) writes:
> > We already use P_ in most cases (under src/), and __P in a few other
> > cases (mostly under lib-src/ and lwlib/).
> > 
> > So it seems a bit odd that pop.c (as the only file) uses _P.
> > 
> > I suggest we simply change pop.c to use __P like the other files in
> > lib-src.
> 
> Both "__P" and "_P" are both firmly and totally in the compiler domain
> (anything matching the regexp /^_[_A-Z]/ is).  Compilers can use these
> symbols however they see fit.  "P_" OTOH is free for use in user
> programs.  So if a change is needed anyway, it should be to "P_"
> (IMO).

True, but the specific problem is with cygwin and the _P in pop.c;
there doesn't seem to have been reported similar problems with __P, so
we have two options:

1) a small, localized change in pop.c (_P => __P)
2) a wider, non-localized change (_P and __P => P_)

Actually, doing 1 now doesn't mean that we cannot do 2 later...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: 21.3.50 for Cygwin: patch 5

[Joe Buehler]

Kim F. Storm wrote:

> True, but the specific problem is with cygwin and the _P in pop.c;
> there doesn't seem to have been reported similar problems with __P, so
> we have two options:
> 
> 1) a small, localized change in pop.c (_P => __P)
> 2) a wider, non-localized change (_P and __P => P_)
> 
> Actually, doing 1 now doesn't mean that we cannot do 2 later...

FYI, I just checked some of the machines I have access to.  AIX 4.3 and
5.1 both have NLctype.h that defines _P.  HPUX 10.20, 11.0 and 11i
all have _P defined in ctype.h.  SunOS 5.8 has _P defined in
/usr/include/iso/ctype_iso.h.  It looks like this is some sort of legacy
thing for character classes.

Joe Buehler

Re: 21.3.50 for Cygwin: patch 5

[Richard Stallman]

    2) a wider, non-localized change (_P and __P => P_)

Now that I understand the situation, I think that is best.
It is still a fairly localized change, localized to pop.c.

Would you like to do it?

Re: 21.3.50 for Cygwin: patch 5

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     2) a wider, non-localized change (_P and __P => P_)
> 
> Now that I understand the situation, I think that is best.
> It is still a fairly localized change, localized to pop.c.

Well, I already changed pop.c to use __P instead of _P, as
the files in lib-src (cvtmail.c, etags.c, movemail.c, yow.c)
already use __P rather than P_.  There are other files in
lwlib/ (e.g. xlwmenu.c) and src/ (e.g. gmalloc.c, mktime.c,
and others) which uses __P as well.

What I meant by a "wider, non-localized change" was to change all of
those uses from __P to P_.

> 
> Would you like to do it?

I can do that, but is it _necessary_ ?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: 21.3.50 for Cygwin: patch 5

[Richard Stallman]

      There are other files in
    lwlib/ (e.g. xlwmenu.c) and src/ (e.g. gmalloc.c, mktime.c,
    and others) which uses __P as well.

For gmalloc.c and mktime.c, this was probably because they were copied
from Glibc, which can legitimately use names like __P.  (There's one
exception: unexalpha.c.)

In some sense we ought to change these files not to use __P when
moving the code outside Glibc, but that is unfortunate since it would
require a fork.

However, it would be better to use P_ instead in the other files.
That is more consistent with the rest of Emacs, and with the C standard.

Re: 21.3.50 for Cygwin: patch 5

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>       There are other files in
>     lwlib/ (e.g. xlwmenu.c) and src/ (e.g. gmalloc.c, mktime.c,
>     and others) which uses __P as well.
> 
> For gmalloc.c and mktime.c, this was probably because they were copied
> from Glibc, which can legitimately use names like __P.  (There's one
> exception: unexalpha.c.)
> 
> In some sense we ought to change these files not to use __P when
> moving the code outside Glibc, but that is unfortunate since it would
> require a fork.
> 
> However, it would be better to use P_ instead in the other files.
> That is more consistent with the rest of Emacs, and with the C standard.

The problem is that P_ is defined in src/lisp.h, while __P is defined
in config.h (as defined by configure).  I guess that's why __P is used
outside src/ (and some files in src/ as well).

Defining P_ in config.h (via configure) is of course possible, but
even if we change everything (except the Glibc originated files) to
use P_, we still will have the __P definition in config.h -- so IMO
there really isn't a great need to make this change.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: 21.3.50 for Cygwin: patch 5

[Richard Stallman]

    Defining P_ in config.h (via configure) is of course possible, but
    even if we change everything (except the Glibc originated files) to
    use P_, we still will have the __P definition in config.h

Why would we still have the __P definition in config.h?
Is there some reason we could not delete it, once it was not used?

Re: 21.3.50 for Cygwin: patch 5

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     Defining P_ in config.h (via configure) is of course possible, but
>     even if we change everything (except the Glibc originated files) to
>     use P_, we still will have the __P definition in config.h
> 
> Why would we still have the __P definition in config.h?
> Is there some reason we could not delete it, once it was not used?

The Glibc files mktime.c, gmalloc.c, and strftime.c use it.  mktime.c
and strftime.c does declare it if it isn't defined already, but
gmalloc.c doesn't.

But even mktime.c and strftime.c use different ways to determine how
to define __P ...  Pretty messy.


BTW, if I simply checkout emacs from CVS, how do I know that some
files are _not_ supposed to be changed within the emacs project (such
as mktime.c and regex.c)?   

I still think we need a "tips and tricks" section in e.g. INSTALL-CVS
or admin/README (or a new file somewhere) to mention things a
developer should be aware of when working on emacs source code, notably:
 - requirement for legal papers,
 - what is a "tiny change" (and how they sum up)
 - how to document changes (ChangeLog, NEWS, manual pages)
 - indentation style, use of P_ macro, which header files to use
   (e.g. when should a function be added to lisp.h)
 - how we support multiple platforms [when to duplicate code,
   which files contain platform specific code, etc...]

but also:
 - quick intro to how we use texinfo

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: 21.3.50 for Cygwin: patch 5

[Eli Zaretskii]

> From: storm@cua.dk (Kim F. Storm)
> Date: 10 Jan 2003 10:49:58 +0100
> 
> but also:
>  - quick intro to how we use texinfo

Can you give examples of this?  AFAIK, the Texinfo manual and
standards.texi should have that information already.

Re: 21.3.50 for Cygwin: patch 5

[Kim F. Storm]

"Eli Zaretskii" <eliz@is.elta.co.il> writes:

> > From: storm@cua.dk (Kim F. Storm)
> > Date: 10 Jan 2003 10:49:58 +0100
> > 
> > but also:
> >  - quick intro to how we use texinfo
> 
> Can you give examples of this?  AFAIK, the Texinfo manual and
> standards.texi should have that information already.

The "quick intro" could simply be a pointer to where to find the info
which is already there...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: 21.3.50 for Cygwin: patch 5

[Richard Stallman]

    The Glibc files mktime.c, gmalloc.c, and strftime.c use it.  mktime.c
    and strftime.c does declare it if it isn't defined already, but
    gmalloc.c doesn't.

Whether to rename the symbol __P when copying these files from Glibc
is a painful issue.  To be strictly correct, we should rename it.  But
renaming it would make the files different, and we'd rather they be
identical.  On the third hand, that are probably already different
(though that is a problem we would want to fix).

I guess we may as well leave __P alone unless we can figure out a
solution that is really right.

    I still think we need a "tips and tricks" section in e.g. INSTALL-CVS
    or admin/README (or a new file somewhere) to mention things a
    developer should be aware of when working on emacs source code, notably:
     - requirement for legal papers,
     - what is a "tiny change" (and how they sum up)
     - how to document changes (ChangeLog, NEWS, manual pages)
     - indentation style, use of P_ macro, which header files to use
       (e.g. when should a function be added to lisp.h)
     - how we support multiple platforms [when to duplicate code,
       which files contain platform specific code, etc...]

It is a good idea, but I don't have time to do it.
Would you like to write this?

Note that many of these questions are answered in standards.texi
and maintain.texi, and I think you may as well refer to them
rather than duplicate them.

Re: 21.3.50 for Cygwin: patch 5

[Richard Stallman]

    >  - quick intro to how we use texinfo

    Can you give examples of this?  AFAIK, the Texinfo manual and
    standards.texi should have that information already.

Indeed, if there is any info about using Texinfo that isn't clear
in the Texinfo manual, we should fix the Texinfo manual rather
than adding it elsewhere.