Rebuilding from CVS on Snow Leopard

Rebuilding from CVS on Snow Leopard

[Bart Schaefer]

N.b. "make clean" doesn't remove Src/Modules/*.so -- I had to do that by
hand in order to get them to recompile for 64bit.

"make check" completes cleanly, so the following is mostly informational.

While running configure:

configure: WARNING: libc.h: accepted by the compiler, rejected by the preprocessor!
configure: WARNING: libc.h: proceeding with the compiler's result

configure: WARNING: stdio.h: accepted by the compiler, rejected by the preprocessor!
configure: WARNING: stdio.h: proceeding with the compiler's result

configure: WARNING: wchar.h: accepted by the compiler, rejected by the preprocessor!
configure: WARNING: wchar.h: proceeding with the compiler's result

configure: WARNING: ncurses.h: accepted by the compiler, rejected by the preprocessor!
configure: WARNING: ncurses.h: proceeding with the compiler's result

configure: WARNING: curses.h: accepted by the compiler, rejected by the preprocessor!
configure: WARNING: curses.h: proceeding with the compiler's result

checking where curses key definitions are located... In file included from /usr/include/stdio.h:444,
                 from /usr/include/curses.h:141,
                 from nametmp.c:2:
/usr/include/secure/_stdio.h:46: error: syntax error in macro parameter list
/usr/include/secure/_stdio.h:53: error: syntax error in macro parameter list
/usr/include/curses.h


While compiling:

rlimits.c: In function 'showlimitvalue':
rlimits.c:104: warning: format '%lu' expects type 'long unsigned int', but argument 2 has type 'rlim_t'
rlimits.c:133: warning: format '%lu' expects type 'long unsigned int', but argument 2 has type 'long long unsigned int'
rlimits.c:135: warning: format '%lu' expects type 'long unsigned int', but argument 2 has type 'long long unsigned int'
rlimits.c: In function 'printulimit':
rlimits.c:373: warning: format '%lu' expects type 'long unsigned int', but argument 2 has type 'rlim_t'

gcc -c -I.  -DHAVE_CONFIG_H -DMODULE -Wall -Wmissing-prototypes -O2 -fno-common -o socket..o socket.c
socket.c: In function 'bin_zsocket':
socket.c:106: warning: call to __builtin___strncpy_chk will always overflow destination buffer
socket.c:235: warning: call to __builtin___strncpy_chk will always overflow destination buffer

gcc -c -I.  -DHAVE_CONFIG_H -DMODULE -Wall -Wmissing-prototypes -O2 -fno-common -o zftp..o zftp.c
zftp.c: In function 'zftp_local':
zftp.c:2522: warning: format '%ld' expects type 'long int', but argument 2 has type 'off_t'

Re: Rebuilding from CVS on Snow Leopard

[Jun T.]

At 22:50 -0700 09/09/27, Bart Schaefer wrote:
 >gcc -c -I.  -DHAVE_CONFIG_H -DMODULE -Wall -Wmissing-prototypes -O2 - 
fno-common -o socket..o socket.c
 >socket.c: In function 'bin_zsocket':
 >socket.c:106: warning: call to __builtin___strncpy_chk will always  
overflow destination buffer
 >socket.c:235: warning: call to __builtin___strncpy_chk will always  
overflow destination buffer

MacOSX (and many BSD's as well?) does not define UNIX_PATH_MAX,
and struct sockaddr_un is defined in sys/un.h as

struct  sockaddr_un {
         unsigned char   sun_len;        /* sockaddr len including  
null */
         sa_family_t     sun_family;     /* [XSI] AF_UNIX */
         char            sun_path[104];  /* [XSI] path name (gag) */
};

so we can't define UNIX_PATH_MAX to 108.

I think it would be better to use sizeof(soun.sun_path) in place
of UNIX_PATH_MAX. Or use sizeof(soun.sun_path)-1 so that sun_path
is always null terminated.


Index: Src/Modules/socket.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Modules/socket.c,v
retrieving revision 1.13
diff -u -r1.13 socket.c
--- Src/Modules/socket.c	22 Sep 2009 16:04:15 -0000	1.13
+++ Src/Modules/socket.c	29 Sep 2009 10:11:35 -0000
@@ -33,10 +33,6 @@
  #include <sys/socket.h>
  #include <sys/un.h>

-#ifndef UNIX_PATH_MAX
-# define UNIX_PATH_MAX 108
-#endif
-
  /*
   * We need to include the zsh headers later to avoid clashes with
   * the definitions on some systems, however we need the configuration
@@ -103,7 +99,7 @@
  	}

  	soun.sun_family = AF_UNIX;
-	strncpy(soun.sun_path, localfn, UNIX_PATH_MAX);
+	strncpy(soun.sun_path, localfn, sizeof(soun.sun_path)-1);

  	if (bind(sfd, (struct sockaddr *)&soun, sizeof(struct sockaddr_un)))
  	{
@@ -232,7 +228,7 @@
  	}

  	soun.sun_family = AF_UNIX;
-	strncpy(soun.sun_path, args[0], UNIX_PATH_MAX);
+	strncpy(soun.sun_path, args[0], sizeof(soun.sun_path)-1);
  	
  	if ((err = connect(sfd, (struct sockaddr *)&soun, sizeof(struct  
sockaddr_un)))) {
  	    zwarnnam(nam, "connection failed: %e", errno);

Re: Rebuilding from CVS on Snow Leopard

[Peter Stephenson]

On Tue, 29 Sep 2009 21:05:13 +0900
"Jun T." <takimoto-j@kba.biglobe.ne.jp> wrote:
> MacOSX (and many BSD's as well?) does not define UNIX_PATH_MAX,
> and struct sockaddr_un is defined in sys/un.h as
> 
> struct  sockaddr_un {
>          unsigned char   sun_len;        /* sockaddr len including  
> null */
>          sa_family_t     sun_family;     /* [XSI] AF_UNIX */
>          char            sun_path[104];  /* [XSI] path name (gag) */
> };
> 
> so we can't define UNIX_PATH_MAX to 108.
> 
> I think it would be better to use sizeof(soun.sun_path) in place
> of UNIX_PATH_MAX. Or use sizeof(soun.sun_path)-1 so that sun_path
> is always null terminated.

Thanks, looks reasonable and I've committed it.

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Re: Rebuilding from CVS on Snow Leopard

[Bart Schaefer]

On Sep 29,  9:05pm, Jun T. wrote:
} Subject: Re: Rebuilding from CVS on Snow Leopard
}
} I think it would be better to use sizeof(soun.sun_path) in place
} of UNIX_PATH_MAX. Or use sizeof(soun.sun_path)-1 so that sun_path
} is always null terminated.

How about this, then?

Index: socket.c
===================================================================
RCS file: /extra/cvsroot/zsh/zsh-4.0/Src/Modules/socket.c,v
retrieving revision 1.9
diff -c -r1.9 socket.c
--- socket.c	26 Nov 2007 17:38:14 -0000	1.9
+++ socket.c	29 Sep 2009 14:42:00 -0000
@@ -34,7 +34,7 @@
 #include <sys/un.h>
 
 #ifndef UNIX_PATH_MAX
-# define UNIX_PATH_MAX 108
+# define UNIX_PATH_MAX (sizeof(soun.sun_path)-1)
 #endif
 
 /*


(Or the equivalent without the dependency on the local variable name
"soun".)

Re: Rebuilding from CVS on Snow Leopard

[Jun T.]

On 2009/09/29, at 23:44, Bart Schaefer wrote:
> How about this, then?

Then it would be better to define UNIX_PATH_MAX to sizeof(soun.sun_path)
and use UNIX_PATH_MAX-1 in strncpy().
(I'm assuming sun_path must be null terminated; is this correct?)

Re: Rebuilding from CVS on Snow Leopard

[Jun T.]

On 2009/09/28, at 14:50, Bart Schaefer wrote:

> configure: WARNING: libc.h: accepted by the compiler, rejected by  
> the preprocessor!


This is due to the lines 464-467 of configure.ac:

dnl Default preprocessing on Mac OS X produces warnings
case "$host_os" in
   darwin*) CPP="$CPP -traditional-cpp" ;;
esac

I don't know when and why this is added. It seems -traditional-cpp is
not required already on Leopard (darwin9.x.x), but maybe it would be
better to modify only for Snow Leopard (darwin10.x.x).

On Snow Leopard, _FORTIFY_SOURCE is defined to 2 by default, and
stdio.h and string.h include files under /usr/include/secure/.
This adds some buffer overflow checks, as in the case of strncpy().
But some macros in /usr/include/secure/_stdio.h can't be processed
by gcc -E -traditional-cpp, and causes the above warning from configure.


Index: configure.ac
===================================================================
RCS file: /cvsroot/zsh/zsh/configure.ac,v
retrieving revision 1.127
diff -u -r1.127 configure.ac
--- configure.ac	7 Sep 2009 08:53:48 -0000	1.127
+++ configure.ac	29 Sep 2009 17:18:17 -0000
@@ -462,8 +462,9 @@
  AC_C_CONST                  dnl Does compiler support `const'.

  dnl Default preprocessing on Mac OS X produces warnings
+dnl Mac OS X 10.6 (darwin10.x.x) does not need this.
  case "$host_os" in
-  darwin*) CPP="$CPP -traditional-cpp" ;;
+  darwin[[0-9]].*) CPP="$CPP -traditional-cpp" ;;
  esac

  fp_PROG_CC_STDC

Re: Rebuilding from CVS on Snow Leopard

[Mikael Magnusson]

2009/9/29 Jun T. <takimoto-j@kba.biglobe.ne.jp>:
> On 2009/09/28, at 14:50, Bart Schaefer wrote:
>
>> configure: WARNING: libc.h: accepted by the compiler, rejected by the
>> preprocessor!
>
>
> This is due to the lines 464-467 of configure.ac:
>
> dnl Default preprocessing on Mac OS X produces warnings
> case "$host_os" in
>  darwin*) CPP="$CPP -traditional-cpp" ;;
> esac
>
> I don't know when and why this is added.

The comment in the commit and the changelog entry don't exactly seem
to match up, but maybe the second hunk is the actual change?

5b8b7e9f06c
Author: Oliver Kiddle <opk@users.sourceforge.net>  2004-03-14 12:27:28
19619: fix problem with getting signals on MacOS X 10.1

---------------------------------- ChangeLog ----------------------------------
+2004-03-14  Oliver Kiddle  <opk@zsh.org>
+
+	* 19619: configure.ac: fix problem with getting signals
+	on MacOS X 10.1

--------------------------------- configure.ac ---------------------------------
@@ -399,32 +399,37 @@ esac
 case " ${LIBLDFLAGS+$LIBLDFLAGS }" in
   " ") ;;
   *" -s "*) strip_libldflags=true
     LIBLDFLAGS=`echo " $LIBLDFLAGS " | sed "$sed"` ;;
   *) strip_libldflags=false ;;
 esac

 AC_SUBST(CFLAGS)dnl
 AC_SUBST(LDFLAGS)dnl
 AC_SUBST(EXELDFLAGS)dnl
 AC_SUBST(LIBLDFLAGS)dnl

 AC_PROG_CPP                 dnl Figure out how to run C preprocessor.
 AC_PROG_GCC_TRADITIONAL     dnl Do we need -traditional flag for gcc.
 AC_C_CONST                  dnl Does compiler support `const'.

+dnl Default preprocessing on Mac OS X produces warnings
+case "$host_os" in
+  darwin*) CPP="$CPP -traditional-cpp" ;;
+esac
+
 fp_PROG_CC_STDC
 AC_MSG_CHECKING([whether to use prototypes])
 if test ."$ansi2knr" = .yes || test ."$ansi2knr" = .no; then
   msg="(overridden) "
 else
   msg=
   if test ."$fp_cv_prog_cc_stdc" = .no; then
     ansi2knr=yes
   else
     ansi2knr=no
   fi
 fi
 AH_TEMPLATE([PROTOTYPES],
 [Define to 1 if ANSI function prototypes are usable.])
 if test "$ansi2knr" = yes; then
   AC_MSG_RESULT(${msg}no)
@@ -1219,33 +1224,33 @@ zsh_cv_path_signal_h=$SIGNAL_H
 ])
 SIGNAL_H=$zsh_cv_path_signal_h
 AC_SUBST(SIGNAL_H)dnl

 dnl Where are error names located?  Needed as input for errnames1.awk
 AC_CACHE_CHECK(where error names are located, zsh_cv_path_errno_h,
 [dnl Look at the output from the preprocessor.
 dnl We should get lines of the form `# 1 "/usr/include/errno.h"'
 dnl The following assumes the real definitions are in a file which
 dnl contains the name `err'; we could relax this if necessary,
 dnl but then you can get a rather long list of files to test.
 dnl The backslash substitution is to persuade cygwin to cough up
 dnl slashes rather than doubled backslashes in the path.
 echo "#include <errno.h>" > nametmp.c
 errfile_list="`$CPP nametmp.c |
 sed -n -e 's/^#line[ 	].*\"\(.*\)\"/\1/p' \
-       -e 's/^#[ 	].*\"\(.*\)\"/\1/p' |
+       -e 's/^#[ 	0-9].*\"\(.*\)\"/\1/p' |
 sed 's/\\\\\\\\/\//g' |
 $AWK '{ if (\$1 ~ \"err\") files[[\$1]] = \$1 }
   END { for (var in files) print var }'`"
 rm -f nametmp.c
 for ERRNO_H in $errfile_list /dev/null
 do
   dnl Try to make sure it doesn't get confused by files that don't
   dnl have real error definitions in.  Count definitions to make sure.
   nerrs=`test -f $ERRNO_H && \
   grep '#[ 	]*define[ 	][ 	]*E[0-9A-Z]*[ 	]*[0-9][0-9]*' $ERRNO_H | \
   wc -l | sed 's/[ 	]//g'`
   test "x$nerrs" != x && test "$nerrs" -ge 7 && break
 done
 if test $ERRNO_H = "/dev/null"; then
   AC_MSG_ERROR(ERROR MACROS NOT FOUND:  please report to developers)
 fi

-- 
Mikael Magnusson

Re: Rebuilding from CVS on Snow Leopard

[Jun T.]

On 2009/09/30, at 02:41, Mikael Magnusson wrote
> 19619: fix problem with getting signals on MacOS X 10.1


I've look into 19619: http://www.zsh.org/mla/workers/2004/msg00273.html
I believe we can safely omit -traditional-cpp on Snow Leopard.