[PHP-DEV] Flex check in configure

[Dave Hill]

Hi again,
   I am looking at the flex check in configure.in again. If flex is not 
present, or is not version 2.5.4 then you may get your environment 
dumped to stdout while running configure. This is due to the set command 
being run with no arguments.

Although non-fatal - it certainly is ugly.

Part of the problem with flex versions is that they are not consistant :-p

I took a crack at a fix, but am uncomfortable making the change as I 
don't really have the history on this one. If some of you out there 
would be so kind as to point out any flaws in my reasoning, I would 
apreciate it. (For example, there is a grep for the line containing 
'version' that I don't seem to need with the 3 versions of flex I checked).

If one of you config wizards wants to make the change - be my guest.

Dave

here is what the current test looks like:

set `echo "" | $LEX -V -v --version 2>/dev/null | grep 'version' | cut 
-d ' ' -f
3 | sed -e 's/\./ /g' | sed -e 's/[^0-9 ]//g'`
if test "${1}" != "2" -o "${2}" != "5" -o "${3}" -lt "4"; then
AC_MSG_WARN(You will need flex 2.5.4 or later if you want to 
regenerate
Zend/PHP lexical parsers.)
fi

I am proposing:

flexvers=`echo "" | $LEX -V -v --version 2>/dev/null | sed -e 's/^.* //' 
-e 's/\
./ /g'`
if test ! -z "$flexvers"; then
   set $flexvers
   if test "${1}" != "2" -o "${2}" != "5" -o "${3}" -lt "4"; then
   AC_MSG_WARN(You will need flex 2.5.4 or later if you want to 
regenerate
Zend/PHP lexical parsers.)
   fi
fi



--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Further outstanding 64-bit issues with PHP_4_3

[Dave Hill]

James Devenish wrote:

Remaining zend_parse_parameters problems:

   php4/ext/ftp/php_ftp.c
   php4/ext/sockets/sockets.c
You were right - I missed some changes, although part of it was due to 
the code drift between the head and the 4_3 branch. Submitted to both 
php4 and php_4_3

General LP64 incompatabilities left over from my November patches:

   php4/ext/pgsql/pgsql.c
   php4/ext/standard/url_scanner.c
   php4/ext/standard/url_scanner_ex.c
 

Understood and in php5, waiting for Jani's go ahead for php 4_3

   php4/main/network.c  
   php4/main/streams.c
   (Need to check: is _php_stream_cast safe? If not, then
   main/streams/cast.c in HEAD is probably not)
   php4/main/streams/plain_wrapper.c
   php4/main/streams/xp_socket.c
While I *think* these are the correct changes I am puzzled by some 
aspects of the zend internals (am still too new to it) and need to look 
at these some more. They don't apply to the php5 stream as far as i can 
tell.

And of course the OnUpdateLong stuff, but I guess that's in process.

I changed the ints where needed but left the procedure OnUpdateInt, the 
name change is in php5.  I *think* this is complete in the php4 streams. 
Jani did the OnUpdateLong in php5, I fixed up the ints where they needed 
to be longs.

dave

--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] fun with autoconf on Tru64

[Dave Hill]

Hi all,
   I am having fun with [EMAIL PROTECTED]@#$ autoconf. In the past I always used 
the configure in the RC tarball without (much) problem. As I am trying 
to be a good little commiter, I am trying to build my potential changes 
out of cvs and am starting with buildconf.

I have installed:
   gawk-3.1.1
   m4-1.4o
   bison-1.875
   flex-2.5.27
   autoconf-2.13
   automake-1.5
   libtool-1.4.3
I get warnings/errors during buildconf, and then syntax errors in the 
./configure after.

Any suggestions ?

# ./buildconf
using default Zend directory
buildconf: checking installation...
buildconf: autoconf version 2.13 (ok)
buildconf: automake version 1.5 (ok)
buildconf: libtool version 1.4.3 (ok)
rebuilding configure
configure.in:564: AC_TRY_COMPILE was called before AC_AIX
configure.in:564: AC_TRY_RUN was called before AC_AIX
configure.in:564: AC_TRY_COMPILE was called before AC_AIX
configure.in:564: AC_TRY_RUN was called before AC_AIX
autoconf: Undefined macros:
***BUG in Autoconf--please report*** AC_ACVERSION
***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF
***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF
***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF
***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF
***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF
***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF
***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF
***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF
rebuilding acconfig.h
rebuilding main/php_config.h.in
configure.in:564: AC_TRY_COMPILE was called before AC_AIX
configure.in:564: AC_TRY_RUN was called before AC_AIX
configure.in:564: AC_TRY_COMPILE was called before AC_AIX
configure.in:564: AC_TRY_RUN was called before AC_AIX


--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [PATCH] - 64 bit issue with zend_parse_parameters calls

[Dave Hill]

Hi all, I am back again

Diff against php4-STABLE-200302241430
   (without the last patch I suggested)
Applies to 4.5.x and 5.x as well.
Affects any 64 bit OS.
I ran into another problem after I turned optimization back on. Usually
these are hell to find, but Julien Soula (who I met through the
bug database) had encountered this already.
This time I have a 64 bit issue with zend_parse_parameters().
Luckily the problem is not the implementation, rather the usage.
"s" -> needs a char *, int *
"l" -> needs a long *
Passing the wrong type into this function will have  unexpected
results... :-) In my case I was getting string lengths with random
values in the upper 32 bits making for strings a bit longer than
in reality.
I did a code inspection (helped by cscope) of the 480 hits,
checking what the types were passed for s & l entries. I did this
regardless of if I actually use the code - it was just easier to
look at them all, but this does mean that I will not be compile
testing all of them I have 26 changed files. I hope the
diff will work against 4.5.x and later because that was a lot of
files to inspect :-p
Where a type like size_t or an enum was used, I converted this to
a long. I did this because the function is defined as taking a
long, and in some cases (like enum) you may actually be getting
an int. Even in a case like size_t where you are probablly safe,
I have always found it to be safe then sorry.
Interestingly enough I did find one coding error, in
ext/w32api/w32api.c there are two calls with "s|l" and only
two arguments passed into the function, so heaven help anyone
who tries to pass that optional long :-) I guess it is lucky
that I am using Apache/Unix :-)
Per README.SUBMITTING_PATCH I am trying to copy all
of the extension owners.
Files affected:
   ./ext/domxml/php_domxml.c
   ./ext/fdf/fdf.c
   ./ext/ftp/php_ftp.c
   ./ext/ldap/ldap.c
   ./ext/mcrypt/mcrypt.c
   ./ext/mhash/mhash.c
   ./ext/pgsql/pgsql.c
   ./ext/posix/posix.c
   ./ext/dio/dio.c
   ./ext/sockets/sockets.c
   ./ext/standard/exec.c
   ./ext/standard/file.c
   ./ext/standard/fsock.c
   ./ext/standard/head.c
   ./ext/standard/html.c
   ./ext/standard/metaphone.c
   ./ext/standard/string.c
   ./ext/sysvsem/sysvsem.c
   ./ext/zlib/zlib.c
   ./ext/bz2/bz2.c
   ./ext/openssl/openssl.c
   ./ext/rpc/com/com.c
   ./ext/iconv/iconv.c
   ./ext/mbstring/mbstring.c
   ./ext/mbstring/php_mbregex.c
   ./ext/zip/zip.c
   ./main/output.c
--- php4-STABLE-200302241430/./ext/domxml/php_domxml.c  2003-01-10 13:11:03.0 
-0500
+++ php4-STABLE-200302241430.mod2/./ext/domxml/php_domxml.c 2003-03-01 
14:24:23.0 -0500
@@ -1967,7 +1967,8 @@
zval *rv = NULL;
zval *id;
xmlNode *n, *node;
-   int ret, recursive = 0;;
+   int ret; 
+   long recursive = 0;
 
DOMXML_GET_THIS_OBJ(n, id, le_domxmlnodep);
 
@@ -3558,7 +3559,8 @@
zval *arg1, *id, *rv = NULL;
xmlNodePtr node, srcnode;
xmlDocPtr docp;
-   int ret, recursive = 0;
+   int ret; 
+   long recursive = 0;
 
DOMXML_GET_THIS_OBJ(docp, id, le_domxmldocp);
 
@@ -3764,7 +3766,8 @@
int ret; 
char *buffer;
int buffer_len;
-   int mode = 0, prevSubstValue;
+   long mode = 0;
+   int prevSubstValue;
int oldvalue =  xmlDoValidityCheckingDefaultValue;
int oldvalue_keepblanks;
int prevLoadExtDtdValue = xmlLoadExtDtdDefaultValue;
@@ -3850,7 +3853,8 @@
xmlDoc *docp = NULL;
int ret, file_len;
char *file;
-   int mode = 0, prevSubstValue;
+   long mode = 0;
+   int prevSubstValue;
int oldvalue =  xmlDoValidityCheckingDefaultValue;
int oldvalue_keepblanks;
zval *errors = NULL;
@@ -5211,7 +5215,8 @@
xmlDocPtr xmldocp;
char *filename;
int filename_len;
-   int ret, compression = 0;
+   int ret;
+   long compression = 0;
 
DOMXML_GET_THIS(idxsl);
 
--- php4-STABLE-200302241430/./ext/fdf/fdf.c2002-12-31 12:15:19.0 -0500
+++ php4-STABLE-200302241430.mod2/./ext/fdf/fdf.c   2003-03-01 14:24:23.0 
-0500
@@ -554,7 +554,8 @@
 PHP_FUNCTION(fdf_get_ap) {
zval *r_fdf;
char *fieldname, *filename;
-   int fieldname_len, filename_len, face;
+   int fieldname_len, filename_len;
+   long face;
FDFDoc fdf;
FDFErc err;
FDFAppFace facenr;
@@ -941,7 +942,8 @@
 PHP_FUNCTION(fdf_get_flags) {
zval *r_fdf;
char *fieldname;
-   int fieldname_len, whichflags;
+   int fieldname_len;
+   long whichflags;
FDFDoc fdf;
FDFErc err;
ASUns32 flags;
@@ -997,7 +999,8 @@
 PHP_FUNCTION(fdf_get_opt) {
zval *r_fdf;
char *fieldname;
-   int fieldname_len, element = -1;
+   int fieldname_len;
+   long element = -1;
FDFDoc fdf;
FDFErc err;
 
--- php4-STABLE-200302241430/./ext/ftp/php_ftp.c2003-01-06 23:09:26.

[PHP-DEV] [PATCH] - fix for 64 bit issues with OnUpdateInt

[Dave Hill]

Proposed Patch to address 64 bit issues in PHP v4.3.1

Diff -u against php4-STABLE-200302241430
Also needed in 4.5.x and 5.x
Addresses bugs 20994, 21002, 21822, 20268
Platforms affected, Tru64, Solaris 9, HP-UX, NetBSD/Alpha and
any other 64 bit platform I forgot to mention
A little education first

on some platforms, sizeof(int) != sizeof(long)
This is particularly true on 64 bit platforms.
Mixed int* and long* in these cases can be deadly, and
can cause hard to find problems. This is because if
the machine writes to a long* that is really pointing at
an int, then "extra" data gets written past the end of the
int corrupting whatever is after that int.
Also on 64 bit platforms, only a long is going to be big enough
to hold a pointer, so assigning a pointer value to an int, and then
assigning it back will result in truncation of data.
Lastly, sizeof(size_t) == sizeof(long) which means if you plan to mix
things, don't mix size_t and int.
The particular problem that sparked this patch is a particular problem
with OnUpdateInt called from zlib, as this function assumes a &long is 
passed in,
despite the name. In the source code - this function was passed a long
in about 70% of the cases, an int in rest. What was passed was not
always consitant in a particular source module.

I chose to address this problem by creating OnUpdateLong (in addition to
to existing OnUpdateInt) and sweep though the code changing the call
where needed to match the stucture item. An equally valid fix would be
to change all of those longs to ints.
After performing that sweep, I found there was a small number of other
errors of the int/long type that my compiler found that I corrected and
are included here. There might be more mix and match problems, I only
addressed the ones in the modules I have enabled.
Files affected:
Zend/zend_ini.c
Zend/zend_ini.h
ext/fbsql/php_fbsql.c
ext/hyperwave/hw.c
ext/ingres_ii/ii.c
ext/interbase/interbase.c
ext/ldap/ldap.c
ext/mbstring/mbstring.c
ext/mssql/php_mssql.c
ext/mysql/php_mysql.c
ext/odbc/php_odbc.c
ext/pgsql/pgsql.c
ext/session/session.c
ext/standard/assert.c
ext/standard/file.c
ext/standard/info.c
ext/standard/url_scanner_ex.c
ext/sybase_ct/php_sybase_ct.c
main/main.c
sapi/apache/php_apache.c


--- php4-STABLE-200302241430/Zend/zend_ini.c2002-12-31 12:15:18.0 -0500
+++ php4-STABLE-200302241430.mod/Zend/zend_ini.c2003-02-27 14:25:11.0 
-0500
@@ -427,9 +427,35 @@
return SUCCESS;
 }
 
-
+/*
+ * Note: on 64 bit platforms, sizeof(long) != sizeof(int) and
+ * long* and int* cannot be used interchangably without disaster !
+ * OnUpdateInt or OnUpdateLong must match the resource type !
+ */
 ZEND_API ZEND_INI_MH(OnUpdateInt)
 {
+   int *p;
+#ifndef ZTS
+   char *base = (char *) mh_arg2;
+#else
+   char *base;
+
+   base = (char *) ts_resource(*((int *) mh_arg2));
+#endif
+
+   p = (int *) (base+(size_t) mh_arg1);
+
+   *p = zend_atoi(new_value, new_value_length);
+   return SUCCESS;
+}
+
+/*
+ * Note: on 64 bit platforms, sizeof(long) != sizeof(int) and
+ * long* and int* cannot be used interchangably without disaster !
+ * OnUpdateInt or OnUpdateLong must match the resource type !
+ */
+ZEND_API ZEND_INI_MH(OnUpdateLong)
+{
long *p;
 #ifndef ZTS
char *base = (char *) mh_arg2;
@@ -445,7 +471,6 @@
return SUCCESS;
 }
 
-
 ZEND_API ZEND_INI_MH(OnUpdateReal)
 {
double *p;
--- php4-STABLE-200302241430/Zend/zend_ini.h2002-12-31 12:15:18.0 -0500
+++ php4-STABLE-200302241430.mod/Zend/zend_ini.h2003-02-27 14:25:11.0 
-0500
@@ -171,6 +171,7 @@
 /* Standard message handlers */
 ZEND_API ZEND_INI_MH(OnUpdateBool);
 ZEND_API ZEND_INI_MH(OnUpdateInt);
+ZEND_API ZEND_INI_MH(OnUpdateLong);
 ZEND_API ZEND_INI_MH(OnUpdateReal);
 ZEND_API ZEND_INI_MH(OnUpdateString);
 ZEND_API ZEND_INI_MH(OnUpdateStringUnempty);
--- php4-STABLE-200302241430/ext/fbsql/php_fbsql.c  2003-02-12 16:13:08.0 
-0500
+++ php4-STABLE-200302241430.mod/ext/fbsql/php_fbsql.c  2003-02-27 14:25:11.0 
-0500
@@ -358,14 +358,14 @@
 /* {{{ PHP_INI
  */
 PHP_INI_BEGIN()
-   STD_PHP_INI_BOOLEAN  ("fbsql.allow_persistent", "1",   
 PHP_INI_SYSTEM, OnUpdateInt,allowPersistent,  zend_fbsql_globals, 
fbsql_globals)
-   STD_PHP_INI_BOOLEAN  ("fbsql.generate_warnings","0",   
 PHP_INI_SYSTEM, OnUpdateInt,generateWarnings, zend_fbsql_globals, 
fbsql_globals)
-   STD_PHP_INI_BOOLEAN  ("fbsql.autocommit",  
 "1",PHP_INI_SYSTEM, OnUpdateInt,autoCommit,   
zend_fbsql_globals, fbsql_globals)
-   STD_PHP_INI_ENTRY_EX ("fbsql.max_persistent",   "-1",  
 PHP_INI_SYSTEM, OnUpdateInt,maxPersistent,zend_fbsql_globals, 
fbsql_globals, display_link_numbers)
-   STD_PHP_INI_ENTRY_EX ("fbsql.max_links",   
 "