[PHP-DEV] Build failing --without-pear
Hello Sascha, the build is failing with the following message when compiling --without-pear: installing shared modules into /usr/local/lib/php/extensions/debug-zts-20010901 shtool:mkdir:Error: invalid number of arguments (at least 1 expected) shtool:mkdir:Hint: run `/dat/dev/php/php-4.3.0dev/build/shtool mkdir -h' or `man shtool' for details +--+ | The installation process is incomplete. The following resources were | | not installed: | | | | Self-contained Extension Support | | PEAR: PHP Extension and Add-on Repository | | | | To install these components, become the superuser and execute: | | | | # make install-su | +--+ make: *** [install-data-local] Error 5 I checked the Makefile and found that the problem lies here: (line 276). install-data-local: if $(mkinstalldirs) $(INSTALL_ROOT)$(peardir); then \ it seems that $(INSTALL_ROOT)$(peardir) is empty for some reason. regards, Derick -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] need help!
You're asking on the wrong list. It's php-general you need to subscribe to.
This list is for development *OF* PHP, not IN PHP.
-Original Message-
From: its me [mailto:[EMAIL PROTECTED]]
Sent: 10 March 2002 06:01
To: [EMAIL PROTECTED]
Subject: [PHP-DEV] need help!
i have in java script an array:
var computerArray = new Array(('Select sub-category','',true,true),
('Hardware'),
('Monitors'),
('Printers'),
('Other'));
but i want to create the items:
('Hardware'),
('Monitors'),
('Printers'),
('Other')
dynamicaly from database
and this array must stay in javascript i can't create it with
only php because its elements are a drop down menu which change
with the change of another drop down menu..so it must remain in
javascript...
the whole script is:
script language=JavaScript
!--
var computerArray = new Array(('Select sub-category','',true,true),
('Hardware'),
('Monitors'),
('Printers'),
('Other'));
var carsArray = new Array(('Select sub-category','',true,true),
('Vans'),
('Sedan'),
('Spor'),
('Other'));
function populateCategory(inForm,selected) {
var selectedArray = eval(selected + Array);
while (selectedArray.length inForm.subcategory.options.length) {
inForm.subcategory.options[(inForm.subcategory.options.length -
1)] = null;
}
for (var i=0; i selectedArray.length; i++) {
eval(inForm.subcategory.options[i]= + new Option + selectedArray[i]);
}
if (inForm.category.options[0].value == '') {
inForm.category.options[0]= null;
if ( navigator.appName == 'Netscape') {
if (parseInt(navigator.appVersion) 4) {
window.history.go(0);
}
else {
if (navigator.platform == 'Win32' || navigator.platform == 'Win16') {
window.history.go(0);
}
}
}
}
}
// End --
/script
html
BODY bgcolor=#FF text=#00
center
form name=globe
select name=category
onChange=populateCategory(document.globe,document.globe.category.
options[document.globe.category.selectedIndex].value)
option selected value=''Select Category/option
option value='cars'Cars/option
option value='computer'Computer/option
/select
select name=subcategory
option value=''/option
/select
/form
/center
/SCRIPT
Rehab M.Shouman
-
Express yourself with a super cool email address from BigMailBox.com.
Hundreds of choices. It's free!
http://www.bigmailbox.com
-
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Non-Existent function Error
Hi Devs, Sorry to ask this question Here, but I already tried general mailing list enough so to come here. How can I capture Error thrown by php for Non existent or undefined function. I used set_error_handler() but its not at all capturing, It silently IGNORING the error. Hope some light on this. Thanks. [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Patch: ext/openssl/openssl.c
In sync with the HEAD version of datetime.c openssl.c needs a similar patch, as attached. It then does compile, make and make install, but doesn't work as an apache module. It creates 3 SIGSEVs and then exits with a 0200 code. gdb isn't able to bt, under run -X. Removing openssl from the modules, works, but then curl fails and there's no with-openssl-dir in ext/curl/config.m4. Further more: apache_1.3.23/src/Makefile needs a small adjustment, as below. With that adjustment, I've now been able to compile: './configure' '--prefix=/usr/local/php' '--with-apache=../apache_1.3.23' '--enable-debug' '--without-pear' '--enable-magic-quotes' '--disable-short-tags' '--enable-trans-sid' '--enable-session' '--disable-xml' '--with-pgsql=/usr' '--with-bz2' '--with-gdbm' '--enable-ftp' apache_1.3.23/src/Makefile.patch: --- Makefile.dist Sun Mar 10 13:54:37 2002 +++ MakefileSun Mar 10 14:00:28 2002 -109,7 +109,7 lib$(TARGET).$(SHLIB_SUFFIX_NAME): subdirs modules.o $(CC) -c $(INCLUDES) $(CFLAGS) buildmark.c - $(LD_SHLIB) $(LDFLAGS_SHLIB) -o lib$(TARGET).$(SHLIB_SUFFIX_NAME) buildmark.o $(OBJS) $(REGLIB) $(EXPATLIB) $(LD_SHCORE_DEF) $(LD_SHCORE_LIBS) + $(LD_SHLIB) $(LDFLAGS_SHLIB) -o lib$(TARGET).$(SHLIB_SUFFIX_NAME) buildmark.o $(OBJS) $(REGLIB) $(EXPATLIB) $(LD_SHCORE_DEF) $(LD_SHCORE_LIBS) $(LIBS) if [ .$(SHLIB_SUFFIX_LIST) != . ]; then \ rm -f lib$(TARGET).$(SHLIB_SUFFIX_NAME).*; \ for suffix in $(SHLIB_SUFFIX_LIST) ; do \ Met vriendelijke groeten / With kind regards, IDG.nl Melvyn Sopacua Webmaster openssl.patch Description: Binary data --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.333 / Virus Database: 187 - Release Date: 8-3-2002 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CLI: Passing arguments to scripts....
The following path for cli version is concerned with passing arguments
to scripts. I found out that not all ways work correct and $PHP_SELF is not set
at all. The four example below explain the patch. All four execute:
echo $PHP_SELF\n;
echo join($argv,',').\n;
1) Execute a file using -f and pass 'a -b c' - before patch scriptfile was
set to a - didn't work
$ php -f /t/temp/arg.php a -b c
/t/temp/arg.php
/t/temp/arg.php,a,-b,c
2) Execute a file using without and pass 'a -b c' - before patch
scriptfile was set to a - didn't work
$ php /t/temp/arg.php a -b c
/t/temp/arg.php
/t/temp/arg.php,/t/temp/arg.php,a,-b,c
3) Execute code directly and pass 'a -b c' - before patch scriptfile was
set to a - didn't work
$ php -r 'echo $PHP_SELF\n.join($argv,,).\n;' a -b c
-
-,a,-b,c
4) Execute stdin and pass 'a -b c' - before patch passing arguments wasn't
possible at all
$ echo '?echo $PHP_SELF\n.join($argv,,).\n;?' | php -- a -b c
-
-,a,-b,c
There was no need to change function ap_php_getopt as it does handle -- to
end interpreting arguments.
But i added PHP_SELF and set it to either the executed script or - for
stdin/run code. The
value for argv[0] seen by script is set to the same value to make argument
enumerating consistent.
An opportunity would be setting argv[0] of script to argv[0] of cli. This
way the user could get the
execution-path on some systems.
Any suggenstions? May i commit the change?
regards
marcus
diff -u -w -r1.9 php_cli.c
--- sapi/cli/php_cli.c 8 Mar 2002 09:55:58 - 1.9
+++ sapi/cli/php_cli.c 10 Mar 2002 14:53:17 -
@@ -240,7 +241,9 @@
prog = php;
}
- php_printf(Usage: %s [-h] [-s] [-v] [-i] [-f file] | {file
[args...]}\n
+ php_printf( Usage: %s [options] [-f] file [args...]\n
+ %s [options] -r code [args...]\n
+ %s [options] [-- args...]\n
-s Display colour syntax
highlighted source.\n
-w Display source with
stripped comments and whitespace.\n
-f file Parse file.\n
@@ -253,8 +256,12 @@
-l Syntax check only (lint)\n
-m Show compiled in modules\n
-i PHP information\n
- -r code Run PHP code\n
- -h This help\n, prog);
+ -r code Run PHP code without
using script tags ?..?\n
+ -h This help\n
+ \n
+ args...Arguments passed to
script. Use -- args when first argument \n
+starts with - or script
is read from stdin\n
+ , prog, prog, prog);
}
/* }}} */
@@ -301,6 +308,7 @@
int no_headers=1;
int orig_optind=ap_php_optind;
char *orig_optarg=ap_php_optarg;
+ char *arg_free=NULL, **arg_excp=arg_free;
char *script_file=NULL;
zend_llist global_vars;
int interactive=0;
@@ -512,18 +520,32 @@
}
}
+ /* only set script_file if not set already and not in
direct mode and not at end of parameter list */
+ if (argc ap_php_optind !script_file !exec_direct
strcmp(argv[ap_php_optind-1],--)) {
+ script_file=argv[ap_php_optind];
+ }
+
CG(interactive) = interactive;
- SG(request_info).argc=argc-ap_php_optind;
- SG(request_info).argv=argv+ap_php_optind;
- if (argc ap_php_optind) {
- script_file=argv[ap_php_optind];
+ /* before registering argv to modulule exchange the *new*
argv[0] */
+ /* we can achieve this without allocating more memory */
+ SG(request_info).argc=argc-ap_php_optind+1;
+ arg_excp = argv+ap_php_optind-1;
+ arg_free = argv[ap_php_optind-1];
+ if (script_file) {
+ argv[ap_php_optind-1] = script_file;
+ } else {
+ argv[ap_php_optind-1] = -; /* should be stdin */
}
+ SG(request_info).argv=argv+ap_php_optind-1;
if (php_request_startup(TSRMLS_C)==FAILURE) {
php_module_shutdown(TSRMLS_C);
+ *arg_excp = arg_free;
return FAILURE;
}
+ *arg_excp = arg_free; /* reconstuct argv */
if (no_headers) {
SG(headers_sent) = 1;
SG(request_info).no_headers = 1;
@@ -535,6 +557,7 @@
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /main rfc1867.c
Modified files: /php4/mainrfc1867.c Log: Fix: Now returns correct Content-Type with Opera 6.01 Hi Stefan, could you shortly explain why a single browser needs such a workaround? Since Opera 6.01 is less than a month old, shouldn't they be the ones fixing such a problem? Have you talked to them about it? --Marko -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /main rfc1867.c
Hi Stefan, could you shortly explain why a single browser needs such a workaround? Since Opera 6.01 is less than a month old, shouldn't they be the ones fixing such a problem? Have you talked to them about it? It is not really a workaround it makes the fileupload behave more RFC conform. The Content-Type header is a header like all others. And Opera adds a special attribute called name to it. That is perfectly legal from the RFC point of view. The workaround in the upload script now strips all attributes away cause we only need the Content-Type value, not the attributes. Stefan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 2 patches for zlib.c - should fix #14939 + #15930
Hello!
I have two patches for zlib.c, but before commiting, I would like to
hear some comments.
First patch (should fix bug #14939):
I could reproduce #14939 even with a simple C program, so I think,
it's rather a very unusual behaviour of the zlib library which seems
to want to read a little bit more than it needs (we are using an
undocumented function (which everybody seems to use), so I don't want
to call it a bug ...).
But I'm unsure, if the fix is really correct. If the input of
gzinflate() comes directly from gzdeflate(), I'm allowed to read this
additional byte, because gzdeflate() added a trailing \0 like many
string operations which deal with binary strings. But are there
circumstances where there isn't this trailing \0 (and I'm dealing with
deflated data)?
(I think, with this patch it can't get worse as the actual situation,
because this additional byte is only used in the (very rare)
circumstances where the zlib library wants to read it. I could
reproduce this with strings of 'a' of length about 15, not much more
and not much less).
Second patch (related to bug #15930):
There was an error in the documentation, the gzencode() function was
misdocumented to have a second optional level parameter, but this was
an encoding mode, not the compression level. I fixed this and added an
additional parameter level, so that you can now give the compression
level.
But how should I add it? The problem is, if you use it with the
required and one optional parameter, should it behave like in the
documentation (gzencode($data [, $level [, $mode]])) or like the (old)
source (gzencode($data [, $mode [, $level]])) ? What do you think?
In my patch I used the form gzencode($data [, $level [, $mode]]),
because I think, the mode parameter isn't really needed. I also think
that there were some problems with the old gzencode() function, it
isn't clear to me, why it should have worked reliably in conjunction
with output compression, so I rewrote this routine. I tried to keep
the old behaviour, so you can give a mode of FORCE_DEFLATE and then
you get a normal zlib deflated string plus the gzip file header but
without the trailing checksum.
Can you please test it a little bit and if nobody objects, I'll commit
it to HEAD.
(Derick: these are two bug fixes, please tell me, if I should commit
them to PHP_4_2_0).
Stefan
--
Stefan Röhrich [EMAIL PROTECTED], [EMAIL PROTECTED]
http://www.roehri.ch/~sr/
--- /home/sr/cvs/php/php4/ext/zlib/zlib.c Thu Mar 7 16:38:26 2002
+++ ext/zlib/zlib.c Thu Mar 7 23:15:48 2002
@@ -967,7 +967,7 @@
if(! s2) { if(s1) efree(s1); RETURN_FALSE; }
stream.next_in = (Bytef*) Z_STRVAL_PP(data);
- stream.avail_in = (uInt) Z_STRLEN_PP(data);
+ stream.avail_in = (uInt) Z_STRLEN_PP(data) + 1; /* there is room for
+\0 */
stream.next_out = s2;
stream.avail_out = (uInt) length;
--- /home/sr/cvs/php/php4/ext/zlib/zlib.c Thu Mar 7 16:38:26 2002
+++ ext/zlib/zlib.c Sun Mar 10 13:22:42 2002
@@ -76,6 +76,8 @@
#define OS_CODE0x03 /* FIXME */
#define CODING_GZIP1
#define CODING_DEFLATE 2
+#define GZIP_HEADER_LENGTH 10
+#define GZIP_FOOTER_LENGTH 8
/* True globals, no need for thread safety */
static int le_zp;
@@ -1124,36 +1126,104 @@
}
/* }}} */
-/* {{{ proto string gzencode(string data [, int encoding_mode])
+/* {{{ proto string gzencode(string data [, int level [, int encoding_mode]])
GZ encode a string */
PHP_FUNCTION(gzencode)
{
- zval **zv_coding, **zv_string;
- int coding;
+ char *data, *s2;
+ int data_len;
+ int level = Z_DEFAULT_COMPRESSION, coding = CODING_GZIP;
+ int status;
+ z_stream stream;
- switch(ZEND_NUM_ARGS()) {
- case 1:
- if (zend_get_parameters_ex(1, zv_string)==FAILURE) {
+ if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, s|ll, data, data_len,
+level, coding) == FAILURE) {
+ return;
+ }
+
+ if((level-1)||(level9)) {
+ php_error(E_WARNING,gzencode: compression level must be whithin
+-1..9);
+ RETURN_FALSE;
+ }
+
+ if((coding!=CODING_GZIP)(coding!=CODING_DEFLATE)) {
+ php_error(E_WARNING,gzencode: encoding mode must be FORCE_GZIP or
+FORCE_DEFLATE);
+ RETURN_FALSE;
+ }
+
+ stream.zalloc = Z_NULL;
+ stream.zfree = Z_NULL;
+ stream.opaque = Z_NULL;
+
+ stream.next_in = (Bytef*) data;
+ stream.avail_in = data_len;
+
+ stream.avail_out = stream.avail_in + (stream.avail_in/1000) + 15 + 1; /* room
+for \0 */
+ s2 = (char *)
+emalloc(stream.avail_out+GZIP_HEADER_LENGTH+(coding==CODING_GZIP?GZIP_FOOTER_LENGTH:0));
+ if(!s2)
+ RETURN_FALSE;
+
+ /* add gzip file header */
+ s2[0] =
[PHP-DEV] PHP FastCGI update
I've just uploaded a new build of the ISAPI/NSAPI FastCGI modules, fixing a bug on error output and a problem in the readme.txt file that prevented proper configuration. Further details can be found in the php-windows mail list archive at http://aspn.activestate.com/ASPN/Mail/Message/1006937 Downloads of binary, source, and phpfcgi.exe ara available at: http://www.caraveo.com/fastcgi/ Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Build failing --without-pear
Also, the 'phpize' doesn't work. --Jani On Sun, 10 Mar 2002, Derick Rethans wrote: Hello Sascha, the build is failing with the following message when compiling --without-pear: installing shared modules into /usr/local/lib/php/extensions/debug-zts-20010901 shtool:mkdir:Error: invalid number of arguments (at least 1 expected) shtool:mkdir:Hint: run `/dat/dev/php/php-4.3.0dev/build/shtool mkdir -h' or `man shtool' for details +--+ | The installation process is incomplete. The following resources were | | not installed: | | | | Self-contained Extension Support | | PEAR: PHP Extension and Add-on Repository | | | | To install these components, become the superuser and execute: | | | | # make install-su | +--+ make: *** [install-data-local] Error 5 I checked the Makefile and found that the problem lies here: (line 276). install-data-local: if $(mkinstalldirs) $(INSTALL_ROOT)$(peardir); then \ it seems that $(INSTALL_ROOT)$(peardir) is empty for some reason. regards, Derick -- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Build failing --without-pear
On Sun, 10 Mar 2002, Jani Taskinen wrote: Also, the 'phpize' doesn't work. It worked when I tested it.. Please elaborate on in which way it fails to work. - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Have you seen the PHP audit project?
Hello everyone, I just read about the PHP audit project on NewsForge. More info here: http://phpaudit.42-networks.com/ Their patch looked great to me, although I didn't browse through all of it... :-) -\- David Eriksson -/- I personally refuse to use inferior tools because of ideology. - Linus Torvalds -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Build failing --without-pear
Yes, it does work..it creates the necessary build stuff, but the resulting modules don't work. I get this with at least ming, curl and ldap extensions: PHP Warning: Invalid library (maybe not a PHP library) 'ldap.so' in Unknown on line 0 This error I get also while configuring: ./configure: /usr/src/web/php/php4/ext/ldap/ext/ldap/Makefile.in: No such file or directory --Jani On Sun, 10 Mar 2002, Sascha Schumann wrote: On Sun, 10 Mar 2002, Jani Taskinen wrote: Also, the 'phpize' doesn't work. It worked when I tested it.. Please elaborate on in which way it fails to work. - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: adamf1
primary for translate documentation to Polish language -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: dallen
To commit a PEAR extension class called XML_XPath which is a DOM frontend for the domxml/xpath functions. It works by building a domxml_xmldoc tree and a pointer, and allows the user to move around in the tree using either the DOM step functions or xpath queries. It feels very much like DB does for databases. It implements XPath_result and XPath_error to handle the appropriate return objects. (I am the same user as [EMAIL PROTECTED]) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Have you seen the PHP audit project?
David Eriksson [EMAIL PROTECTED] wrote: I just read about the PHP audit project on NewsForge. More info here: http://phpaudit.42-networks.com/ Their patch looked great to me, although I didn't browse through all of it... :-) it's unfortunate that they're auditing 4.1.2, instead of the CVS HEAD (or the 4.2 branch). there are definitely parts of that patch that will not apply. a lot has changed since 4.1 branched a zillion years ago. but it is very nice to see someone taking on the task of tightening things up. it is a little annoying to read things in their mailing list archive like One probably exploitable buffer overflow has been fixed, as well as a format string vulnerability. thanks for the heads up, guys. it would be nice if they were feeding us these patches in manageable chunks. one giant patch is unlikely to be accepted quickly. jim -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Build failing --without-pear
Okay, probably a missing -D.. I'll have a look at it tomorrow. On Mon, 11 Mar 2002, Jani Taskinen wrote: Yes, it does work..it creates the necessary build stuff, but the resulting modules don't work. I get this with at least ming, curl and ldap extensions: PHP Warning: Invalid library (maybe not a PHP library) 'ldap.so' in Unknown on line 0 This error I get also while configuring: ./configure: /usr/src/web/php/php4/ext/ldap/ext/ldap/Makefile.in: No such file or directory --Jani On Sun, 10 Mar 2002, Sascha Schumann wrote: On Sun, 10 Mar 2002, Jani Taskinen wrote: Also, the 'phpize' doesn't work. It worked when I tested it.. Please elaborate on in which way it fails to work. - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Suggest: Have PHP Session cookies-enabled check use any cookie
Hi, I don't know if this has been discussed before, but I have a suggestion about how PHP checks whether cookie support is enabled. Here is my understanding of the current setup: On the first PHP page encountered, all links will be turned into GET style URLS with the session id attached because it does not yet know whether cookies are enabled. At the same time, it sends a cookie with the session id back to the client. On the second page view, the session id cookie is sent back to the server and thus the server knows cookies are enabled, and no longer has to modify the links. I've seen a fair number of people complaining about the appearance of the PHPSESSID tacked on the end of all URLs on the first page, and some people doing work-arounds like automatically redirecting back to the home page. I agree with them that it would be nice not to have the URL modification happen, but I don't like the redirect workaround either. So, I have a suggestion: To determine whether cookies are enabled, PHP could simply check to see whether *any* cookie was sent on the page request. If it were set up like this, we could then set a dummy cookie with a long lifetime on their first visit to the site. Then, on all future visits to the site, PHP would discover even on the first page that cookies are enabled. The result would be the PHPSESSID var would only be stuck on the URLs the very first time a user visits the site, and would never appear again (as long as cookies are enabled). If you fear that this is less safe than actually checking for the PHPSESSID variable, it seems that this could at least be an option that could be enabled in php.ini. What do you think? Matt -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Suggest: Have PHP Session cookies-enabled check use any cookie
hi, [..] If it were set up like this, we could then set a dummy cookie with a long lifetime on their first visit to the site. [..] -2 people tend to dislike cookies - many see cookies as a dangerous threat to their privacy and security (that's why IE 6.0 blocks almost all DANGEROUS cookies *cough*). don't force people to use cookies if they don't want to. Daniel Lorch -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Have you seen the PHP audit project?
On Sun, Mar 10, 2002 at 10:22:55PM -, Jim Winstead wrote : David Eriksson [EMAIL PROTECTED] wrote: I just read about the PHP audit project on NewsForge. More info here: http://phpaudit.42-networks.com/ Their patch looked great to me, although I didn't browse through all of it... :-) it's unfortunate that they're auditing 4.1.2, instead of the CVS HEAD (or the 4.2 branch). there are definitely parts of that patch that will not apply. a lot has changed since 4.1 branched a zillion years ago. but it is very nice to see someone taking on the task of tightening things up. it is a little annoying to read things in their mailing list archive like One probably exploitable buffer overflow has been fixed, as well as a format string vulnerability. thanks for the heads up, guys. it would be nice if they were feeding us these patches in manageable chunks. one giant patch is unlikely to be accepted quickly. Anyway it would -very- interesting to get those work integrated into PHP. How should we process .. just talk to those if they're interested in participating and putting their patches into PHP itself too ? Someone else also could just go over the patch and merge it into HEAD (if it's ok with the authors [no idea]). - Markus -- Please always Cc to me when replying to me on the lists. GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Suggest: Have PHP Session cookies-enabled check use any cookie
The good idee is to set a cookie...and if so not to modify anything. What you missed is that you need not get any cookie if you did not write one yourself (but that does not affect your idea). We could simply leave an old session-cookie and reread it - that shouldn't be a security problem. Perhaps we should then take some thoughts about the security of the session cookies. However it is important that we must rewrite the urls for cases where no cookie was received. That makes your idea no solutions for peoples which claim this because for example thier JavaScript code does not work anymore when session cookies rewrite their urls. (My own hp would have the same problem...but i do not change that) marcus At 22:34 10.03.2002, you wrote: Hi, I don't know if this has been discussed before, but I have a suggestion about how PHP checks whether cookie support is enabled. Here is my understanding of the current setup: On the first PHP page encountered, all links will be turned into GET style URLS with the session id attached because it does not yet know whether cookies are enabled. At the same time, it sends a cookie with the session id back to the client. On the second page view, the session id cookie is sent back to the server and thus the server knows cookies are enabled, and no longer has to modify the links. I've seen a fair number of people complaining about the appearance of the PHPSESSID tacked on the end of all URLs on the first page, and some people doing work-arounds like automatically redirecting back to the home page. I agree with them that it would be nice not to have the URL modification happen, but I don't like the redirect workaround either. So, I have a suggestion: To determine whether cookies are enabled, PHP could simply check to see whether *any* cookie was sent on the page request. If it were set up like this, we could then set a dummy cookie with a long lifetime on their first visit to the site. Then, on all future visits to the site, PHP would discover even on the first page that cookies are enabled. The result would be the PHPSESSID var would only be stuck on the URLs the very first time a user visits the site, and would never appear again (as long as cookies are enabled). If you fear that this is less safe than actually checking for the PHPSESSID variable, it seems that this could at least be an option that could be enabled in php.ini. What do you think? Matt -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: pajoye
Need on /pear Maintaining and enhance HTML_OOH_Form on a 1st time. Many bugs fixes, new features, and documentation. In a 2nd step, help on /php4/pear and /pear. and /peardoc : Just launch our pearfr project. Maintaining the french translation of pear core and ext. Pearfr is a part of the afup (french php user group). thank's in advance pierre-alain joye -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] SAPDB compile problem
hi all, Apologize if php-dev is inappropriate, but since this is a compile problem I thought it would be relevant. I have cc:d the sapdb-general list as they should be aware of these compile problems (and that is where I first asked for help). I would like to construct a guide for people using SAPDB with PHP in real multi-machine enterprise situations and will do so when I resolve this compile issue: I'm trying to compile PHP 4.1.1 on RH 6.2 w/SAPDB. Yes, I will upgrade to 4.1.2 very soon :) Problem: During make, I get: /usr/bin/ld: cannot find -lsqlrte Which is surprising because I rsynced my copy of sqlrte into /opt/sapdb/depend/lib from a real install I have on another machine. (the real is a full, current server install... on this machine I only want the client libs) I also used the tarball from ftp://ftp.sap.com/pub/sapdb/bin/patch/sapdb-odbc-linux-i386-7.3.0.21.tgz which is (unless I am wrong, please correct me) fairly useless because it does not contain that sqlrte lib that is required by PHP when compiling --with-sapdb=/opt/sapdb/interfaces/odbc/lib anyway, despite having included the correct path(s): /opt/sapdb/interfaces/odbc/lib /opt/sapdb/depend/lib in ld.so.conf and having run ldconfig... I still get /usr/bin/ld: cannot find -lsqlrte What's worse (and much more confusing): root@core lib ld -v |grep sql /// i.e. no results from this search, which lists all known libs root@core lib ldconfig -v |grep sql libsqlod.so = libsqlod.so libsqlrte.so = libsqlrte.so libsqlcls.so = libsqlcls.so // note that ldconfig _is_ tracking these libs. AGH! I have never seen an instance where ldconfig knows about something ld doesn't. I tried coping all files to /opt/sapdb/interfaces/odbc/lib just to give it a shot, and that didn't work (though I'm not surprised it didn't). I have also tried a number of variations of the --with-sapdb path just to ensure it isn't me being a complete idiot. what should I try next? or better, does anyone know how to solve this problem? PS: PLEASE email me directly. I'll cee my responses and findings to the list, but I'm not subscribed. tia all, _alex project leader, binarycloud http://binarycloud.tigris.org http://www.binarycloud.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] the dl() issue
I want to reopen this issue again. I think dl is an extremely important feature, and issues surrounding it should be fixed. I've looked at the code, gone over email list archives, cvs commits and comments, and even actually thought a little about it. :) So here is a quick outline of needs and issues. Most reasons are from a single thread on the issue last fall. I've thrown a few of my own items in also. Archive of the most pertinent thread on the issue is at http://aspn.activestate.com/ASPN/Mail/Message/php-Dev/715567 My personal main reason for wanting to address this issue is that I think script/c extension combo's are going to become increasingly important in the near future. That in combination with a larger number of extensions, and the desire to have a nice automated extension repository (PEAR), I think dl is an important piece of those features. To me, it mostly comes down to the 'technical issues' I list in one section below. Are there more technical issues? Are they issues we simply cannot overcome? There also seems to be a pertinent change in how dl works that is different from the last time I closely worked on that code (a couple years back). It seems we now unload extensions loaded by dl() after the request is done. I don't really understand why. Seems logical to me that the extension should remain loaded from there on until that process is ended (I believe that is what php3 does). This would do away with performance issues for the most part, and likely would fix or simplify other things. Reasons for it: * As the number of extensions grow, and php becomes more accepted outside the web server, dynamic loading via script will become more important. * It is unreasonable to expect large systems to include all dll's that anyone might need in php.ini, or to have someone load different ini files for different scripts. We already have too much reliance on php.ini as it is. * Placing the entire ability to load dynamic modules into php.ini will be a larger performance hit for smaller scripts. * Every major language I can think of has some method of dynamically loading code, there must be some good reason for that ;). But really, it just seems silly to take it out rather than fix something that every other language does. Reasons against it: * Performance and memory usage - if someone is loading an extension known to take large amounts of memory, long startup, etc., they SHOULD load it in ini to allow apache forking to preserve some of that across processes. * script optimization - one good reason, but not enough to me. * design issues that make it a pain in the ass to fix * having the time to actually fix it * it's just not a sexy enough feature that anyone has a strong desire to deal with Technical Issues: * modules not tested for dynamic loading, so can be buggy when dynamicly loaded/unloaded * multithreaded issues, which I can find no details of except Zeev's cvs comment that it is buggy. An explanation of these issues would be helpful. Other reasons against it that I'm tossing out: * not supported in thread safe mode (why? should be fixable) * it's buggy and insecure (vague, should be fixable) * complicates development of extensions and engine (vague, design issue, and most extensions are already designed -to one extent or another- for use with dl) * module_init is done multiple times (design issue, fixable, even if not fixed, it should only happen once in the lifetime of an executable) * COM extension can be extremely slow if loading type libraries (some extensions SHOULD be loaded from php.ini, but lets not use the exception as an excuse to deprecate dl) * tons of people having to figure out how to get things to load at all under windows (documentation, and perhaps adding extension_dir to the path on load so ISAPI,etc. modules don't have a problem with it.) Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Suggest: Have PHP Session cookies-enabled check use any cookie
I think there has been some confusion as to what I was suggesting for people with cookies disabled. What I am suggesting would have the following effect: (1) If user has cookies disabled: PHP sessions would end up acting as before, they would convert URLs into GET style URLs (2) If user has cookies enabled: PHP sessions would act as before except would not end up rewriting URLs on the first page view. The change to the PHP code should be small: when seeing if cookies are enabled simply look for any cookie sent by the client rather than just the PHPSESSID cookie. Matt Matt Richardson [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Hi, I don't know if this has been discussed before, but I have a suggestion about how PHP checks whether cookie support is enabled. Here is my understanding of the current setup: On the first PHP page encountered, all links will be turned into GET style URLS with the session id attached because it does not yet know whether cookies are enabled. At the same time, it sends a cookie with the session id back to the client. On the second page view, the session id cookie is sent back to the server and thus the server knows cookies are enabled, and no longer has to modify the links. I've seen a fair number of people complaining about the appearance of the PHPSESSID tacked on the end of all URLs on the first page, and some people doing work-arounds like automatically redirecting back to the home page. I agree with them that it would be nice not to have the URL modification happen, but I don't like the redirect workaround either. So, I have a suggestion: To determine whether cookies are enabled, PHP could simply check to see whether *any* cookie was sent on the page request. If it were set up like this, we could then set a dummy cookie with a long lifetime on their first visit to the site. Then, on all future visits to the site, PHP would discover even on the first page that cookies are enabled. The result would be the PHPSESSID var would only be stuck on the URLs the very first time a user visits the site, and would never appear again (as long as cookies are enabled). If you fear that this is less safe than actually checking for the PHPSESSID variable, it seems that this could at least be an option that could be enabled in php.ini. What do you think? Matt -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Suggest: Have PHP Session cookies-enabled check use any cookie
This is an interesting idea -- simply having the old session cookie stay around longer. On the server side, you'd probably want to keep track of the time the session was created and if it's an old session then change the session id (I don't know if that's easy or hard). I think for security it is good for each session to have its own id. Otherwise, if I read your cookies once, I could use your session indefinitely. I think it would be easier if the PHP code was modified to look for any cookie, but if that doesn't happen then I may look into doing something like this instead. Marcus Börger [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... The good idee is to set a cookie...and if so not to modify anything. What you missed is that you need not get any cookie if you did not write one yourself (but that does not affect your idea). We could simply leave an old session-cookie and reread it - that shouldn't be a security problem. Perhaps we should then take some thoughts about the security of the session cookies. However it is important that we must rewrite the urls for cases where no cookie was received. That makes your idea no solutions for peoples which claim this because for example thier JavaScript code does not work anymore when session cookies rewrite their urls. (My own hp would have the same problem...but i do not change that) marcus At 22:34 10.03.2002, you wrote: Hi, I don't know if this has been discussed before, but I have a suggestion about how PHP checks whether cookie support is enabled. Here is my understanding of the current setup: On the first PHP page encountered, all links will be turned into GET style URLS with the session id attached because it does not yet know whether cookies are enabled. At the same time, it sends a cookie with the session id back to the client. On the second page view, the session id cookie is sent back to the server and thus the server knows cookies are enabled, and no longer has to modify the links. I've seen a fair number of people complaining about the appearance of the PHPSESSID tacked on the end of all URLs on the first page, and some people doing work-arounds like automatically redirecting back to the home page. I agree with them that it would be nice not to have the URL modification happen, but I don't like the redirect workaround either. So, I have a suggestion: To determine whether cookies are enabled, PHP could simply check to see whether *any* cookie was sent on the page request. If it were set up like this, we could then set a dummy cookie with a long lifetime on their first visit to the site. Then, on all future visits to the site, PHP would discover even on the first page that cookies are enabled. The result would be the PHPSESSID var would only be stuck on the URLs the very first time a user visits the site, and would never appear again (as long as cookies are enabled). If you fear that this is less safe than actually checking for the PHPSESSID variable, it seems that this could at least be an option that could be enabled in php.ini. What do you think? Matt -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Suggest: Have PHP Session cookies-enabled checkuse any cookie
This is exactly what happens (at least with latest CVS of PHP). If cookies are enabled, URLs are not modified. If cookies are disabled, this is detected and URLs are then modified to contain PHPSESSID. --Jani On Sun, 10 Mar 2002, Matt Richardson wrote: I think there has been some confusion as to what I was suggesting for people with cookies disabled. What I am suggesting would have the following effect: (1) If user has cookies disabled: PHP sessions would end up acting as before, they would convert URLs into GET style URLs (2) If user has cookies enabled: PHP sessions would act as before except would not end up rewriting URLs on the first page view. The change to the PHP code should be small: when seeing if cookies are enabled simply look for any cookie sent by the client rather than just the PHPSESSID cookie. Matt Matt Richardson [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Hi, I don't know if this has been discussed before, but I have a suggestion about how PHP checks whether cookie support is enabled. Here is my understanding of the current setup: On the first PHP page encountered, all links will be turned into GET style URLS with the session id attached because it does not yet know whether cookies are enabled. At the same time, it sends a cookie with the session id back to the client. On the second page view, the session id cookie is sent back to the server and thus the server knows cookies are enabled, and no longer has to modify the links. I've seen a fair number of people complaining about the appearance of the PHPSESSID tacked on the end of all URLs on the first page, and some people doing work-arounds like automatically redirecting back to the home page. I agree with them that it would be nice not to have the URL modification happen, but I don't like the redirect workaround either. So, I have a suggestion: To determine whether cookies are enabled, PHP could simply check to see whether *any* cookie was sent on the page request. If it were set up like this, we could then set a dummy cookie with a long lifetime on their first visit to the site. Then, on all future visits to the site, PHP would discover even on the first page that cookies are enabled. The result would be the PHPSESSID var would only be stuck on the URLs the very first time a user visits the site, and would never appear again (as long as cookies are enabled). If you fear that this is less safe than actually checking for the PHPSESSID variable, it seems that this could at least be an option that could be enabled in php.ini. What do you think? Matt -- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Can't build sapi/cgi
c:\home\php\php4\sapi\cgi\libfcgi\fcgi_stdio.c(34): fatal error C1083: 'fcgios.h': No such file or directory c:\home\php\php4\sapi\cgi\libfcgi\fcgiapp.c(50): fatal error C1083: 'fcgimisc.h': No such file or directory c:\home\php\php4\sapi\cgi\libfcgi\os_win32.c(33): fatal error C1083: 'fcgimisc.h': No such file or directory -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Including bandled expat.h
Any reason not to including bandled expat.h explicitly? Any comments for possible fix? Index: ext/wddx/php_wddx.h === RCS file: /repository/php4/ext/wddx/php_wddx.h,v retrieving revision 1.10 diff -u -r1.10 php_wddx.h --- ext/wddx/php_wddx.h 28 Feb 2002 08:26:56 - 1.10 +++ ext/wddx/php_wddx.h 11 Mar 2002 07:02:18 - -23,7 +23,7 #if HAVE_WDDX -#include expat.h +#include ext/xml/expat/expat.h extern zend_module_entry wddx_module_entry; #define wddx_module_ptr wddx_module_entry Index: ext/xml/php_xml.h === RCS file: /repository/php4/ext/xml/php_xml.h,v retrieving revision 1.19 diff -u -r1.19 php_xml.h --- ext/xml/php_xml.h 11 Dec 2001 15:30:51 - 1.19 +++ ext/xml/php_xml.h 11 Mar 2002 07:02:18 - -35,7 +35,7 #if defined(PHP_XML_INTERNAL) -#include expat.h +#include ext/xml/expat/expat.h #ifdef PHP_WIN32 #define PHP_XML_API __declspec(dllexport) -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 4.1.2 for windows
Hi! From hour to hour we receive questions at [EMAIL PROTECTED] about the availability of PHP 4.1.2 for Windows. First I tried to give an estimate, but now I don't know what to say. Will there ever be a PHP 4.1.2 for windows, or a 4.1.3??? Guys are waiting for the security fix... Why to kick out windows users from installing a more secure version of PHP? Goba -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Including bandled expat.h
On Mon, 11 Mar 2002, Yasuo Ohgaki wrote: Any reason not to including bandled expat.h explicitly? Any comments for possible fix? The bundled file may differ from the used library, so this is not a good idea. Derick Index: ext/wddx/php_wddx.h === RCS file: /repository/php4/ext/wddx/php_wddx.h,v retrieving revision 1.10 diff -u -r1.10 php_wddx.h --- ext/wddx/php_wddx.h 28 Feb 2002 08:26:56 - 1.10 +++ ext/wddx/php_wddx.h 11 Mar 2002 07:02:18 - @@ -23,7 +23,7 @@ #if HAVE_WDDX -#include expat.h +#include ext/xml/expat/expat.h extern zend_module_entry wddx_module_entry; #define wddx_module_ptr wddx_module_entry Index: ext/xml/php_xml.h === RCS file: /repository/php4/ext/xml/php_xml.h,v retrieving revision 1.19 diff -u -r1.19 php_xml.h --- ext/xml/php_xml.h 11 Dec 2001 15:30:51 - 1.19 +++ ext/xml/php_xml.h 11 Mar 2002 07:02:18 - @@ -35,7 +35,7 @@ #if defined(PHP_XML_INTERNAL) -#include expat.h +#include ext/xml/expat/expat.h #ifdef PHP_WIN32 #define PHP_XML_API __declspec(dllexport) -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Site Resource Manager - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Can't build sapi/cgi
I just fixed the problem with that, sorry. Shane Sebastian Bergmann wrote: c:\home\php\php4\sapi\cgi\libfcgi\fcgi_stdio.c(34): fatal error C1083: 'fcgios.h': No such file or directory c:\home\php\php4\sapi\cgi\libfcgi\fcgiapp.c(50): fatal error C1083: 'fcgimisc.h': No such file or directory c:\home\php\php4\sapi\cgi\libfcgi\os_win32.c(33): fatal error C1083: 'fcgimisc.h': No such file or directory -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.1.2 for windows
I have my own compile available at www.caraveo.com/fastcgi/php.zip No, it's not anything to do with fastcgi, I just threw it there as it was a handy location. It's not realy tested out, other than patches for security fixes are included. It doesn't include any additional modules, though the 4.1.1 modules should work with it. If someone needs a quick fix before a compile gets up on php.net, go ahead and download it (at you're own risk, I assume no liabilities). Regards, Shane Caraveo Gabor Hojtsy wrote: Hi! From hour to hour we receive questions at [EMAIL PROTECTED] about the availability of PHP 4.1.2 for Windows. First I tried to give an estimate, but now I don't know what to say. Will there ever be a PHP 4.1.2 for windows, or a 4.1.3??? Guys are waiting for the security fix... Why to kick out windows users from installing a more secure version of PHP? Goba -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.1.2 for windows
It's been lagging big time, mainly because too many people were involved and because the package supplier (Daniel) has very little time right now. Zeev On Mon, 11 Mar 2002, Gabor Hojtsy wrote: Hi! From hour to hour we receive questions at [EMAIL PROTECTED] about the availability of PHP 4.1.2 for Windows. First I tried to give an estimate, but now I don't know what to say. Will there ever be a PHP 4.1.2 for windows, or a 4.1.3??? Guys are waiting for the security fix... Why to kick out windows users from installing a more secure version of PHP? Goba -- Zeev Suraski [EMAIL PROTECTED] http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.1.2 for windows
AFAIK the problem is not afecting windows users. Because of that there is no windows binary. AFAIK it affect Windows. Forwarded letter from Zeev: - Original Message - From: Zeev Suraski [EMAIL PROTECTED] To: Rasmus Lerdorf [EMAIL PROTECTED] Cc: Jonathan Abbett [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, March 02, 2002 2:25 AM Subject: Re: 4.1.2 win binaries? ?! Why not? They will be offered soon. Zeev At 23:07 01/03/2002, Rasmus Lerdorf wrote: They aren't really required since the changes from 4.1.1 should have no effect on Windows. On Fri, 1 Mar 2002, Jonathan Abbett wrote: Will PHP.net be offering ver. 4.1.2 Windows binaries any time soon? Thanks! Jonathan Abbett [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: aspinei
I am in the team for Romanian translation of the PHP documentation (see http://php.urbanxp.org) I'd like to have access at the phpdoc module. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/pgsql pgsql.c
[EMAIL PROTECTED] wrote: On Mon, 11 Mar 2002, Yasuo Ohgaki wrote: yohgaki Mon Mar 11 02:09:13 2002 EDT Modified files: /php4/ext/pgsql pgsql.c Log: Fix possible build error under Windows. # Recent libpq under windows supports PQcmdTuples, right? - get_active_function_name(TSRMLS_C); + get_active_function_name(TSRMLS_C)); This does not seem like a 'fix' to me. This will even break the build. I missed ) when I changed it to use get_active_function_name(). Does this break your build? If so, it's strange :) -- Yasuo Ohgaki [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.1.2 for windows
AFAIK Why not? === Why they are not required? But regardless of this, we should either declare on the website, that they are not required, or release that version. As Zeev pointed out again, it will be available sometime in the future. Goba As far as I see Rasmus says :They aren't really required since the changes from 4.1.1 should have no effect on Windows. And Zeev says : Why not? They will be offered soon. - why not to have 4.1.2 for windows. ?! Why not? They will be offered soon. Zeev They aren't really required since the changes from 4.1.1 should have no effect on Windows. Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
