[PHP-DEV] PHP 4.0 Bug #9891: Finnish mirror is *ucked up

[jiri]

From: [EMAIL PROTECTED]
Operating system: --
PHP version:  4.0.4pl1
PHP Bug Type: Unknown/Other Function
Bug description:  Finnish mirror is *ucked up

Parse error: parse error in /usr/htdocs/mirrors/phpweb/index.php on line 2

This problem occures when entering http://fi.php.net/


-- 
Edit Bug report at: http://bugs.php.net/?id=9891&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9870 Updated: PHP dies with segfault when a post request has no content-type

[teo]

ID: 9870
User Update by: [EMAIL PROTECTED]
Status: Closed
Bug Type: HTTP related
Description: PHP dies with segfault when a post request has no content-type

K, thanks Jani

can you have a look/an opinion if this strstr() stuff
is not exploitable, given the fact that it's triggered
by malformed user data (in this case the post data) ?


Previous Comments:
---

[2001-03-20 09:19:49] [EMAIL PROTECTED]
This is fixed in CVS. A bit differently though.
The check for content_type_dup is put a bit earlier
so it doesn't even get into the handler if it's null.

Try the latest CVS snapshot from http://snaps.php.net/

--Jani


---

[2001-03-20 09:06:01] [EMAIL PROTECTED]

[Tue Mar 20 15:09:20 2001] [error] PHP Warning:  No content-type in POST request in 
Unknown on line 0
Unknown(0) : Warning - No content-type in POST request

Program received signal SIGSEGV, Segmentation fault.
0x400c2073 in strstr () at ../sysdeps/generic/strstr.c:125
125 ../sysdeps/generic/strstr.c: No such file or directory.
(gdb) bt
#0  0x400c2073 in strstr () at ../sysdeps/generic/strstr.c:125
#1  0x401aef39 in rfc1867_post_handler () at rfc1867.c:426
#2  0x401abdd3 in sapi_handle_post () at SAPI.c:54
#3  0x401b0532 in php_treat_data () at php_variables.c:190
#4  0x401a9274 in php_hash_environment () at main.c:1039
#5  0x401a8836 in php_request_startup () at main.c:588
#6  0x401a4fa8 in apache_php_module_main () at sapi_apache.c:98
#7  0x401a5d69 in send_php () at mod_php4.c:433
#8  0x401a5db3 in send_parsed_php () at mod_php4.c:433
#9  0x8076669 in ap_invoke_handler ()
#10 0x808c05f in process_request_internal ()
#11 0x808c0d2 in ap_process_request ()
#12 0x8082c76 in child_main ()
#13 0x8082e55 in make_child ()
#14 0x8082fd6 in startup_children ()
#15 0x808365c in standalone_main ()
#16 0x8083eac in main ()
#17 0x40083a8e in __libc_start_main () at ../sysdeps/generic/libc-start.c:93
(gdb) 

How to reproduce:


Some text here:
File here: 




Using Netscape on Linux, upload a file, then hit
reload (Meta-r) three times. NS will repost it only
two times, then complain /tmp/ns131323gibberish is not
found [a temp file in which it composes the multipart
post]

3rd time when you post it, it won't send proper Content-Type
header and hence the Warning.

The offending code is:
 boundary = strstr(content_type_dup, "boundary");
in main/rfc1867.c:441

Patch:
check content_type_dup for null before strstr()-ing it.
[suggestion]

--- rfc1867.c   Fri Dec  8 18:21:47 2000
+++ /tmp/rfc1867.c  Tue Mar 20 15:59:39 2001
@@ -438,6 +438,11 @@
return;
}

+   if (!content_type_dup) {
+   sapi_module.sapi_error(E_COMPILE_ERROR, "Missing headers in 
+multipart/form-data POST data");
+   return;
+   }
+
boundary = strstr(content_type_dup, "boundary");
if (!boundary || !(boundary=strchr(boundary, '='))) {
sapi_module.sapi_error(E_COMPILE_ERROR, "Missing boundary in 
multipart/form-data POST data");

have fun,
--teodor

---


Full Bug description available at: http://bugs.php.net/?id=9870


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] dirname() bug, advice needed

[André Langhorst]

I would expect different results from dirname() on win32 and linux, I am 
pretty stuck with it, perhaps there is a RFC for this? should this 
function act differently on win32+linux what would make code unportable 
but working correctly?

dirname() seems to be buggy, at least on win32, these are the expected 
values from the test file:

--EXPECT--
dirname(/foo/) == /
dirname(/foo) == /
dirname(/foo/bar) == /foo
dirname(d:\foo\bar.inc) == .
dirname(/) == /
dirname(.../foo) == ...
dirname(./foo) == .
dirname(foobar///) == .
dirname(c:\foo) == .

what I would expect...
dirname(/foo/) == /foo
dirname(/foo) == /
dirname(/foo/bar) == /foo
dirname(d:\foo\bar.inc) == d:\foo
dirname(/) == /
dirname(.../foo) == ? (dunno linux+win32)
dirname(./foo) == . (win32?)
dirname(foobar///) == . (???)
dirname(c:\foo) == 

I really do not know what to do with this issue.

andré



-- 
· André Langhorstt: +49 331 5811560 ·
· [EMAIL PROTECTED]  m: +49 173 9558736 ·
* PHP Quality Assurance  http://qa.php.net  *


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9892: passthru() does not execute all commands in a *.bat-File

[b . rotondi]

From: [EMAIL PROTECTED]
Operating system: Win2000 german
PHP version:  4.0.4pl1
PHP Bug Type: Unknown/Other Function
Bug description:  passthru() does not execute all commands in a *.bat-File

Hello

Congratulation for you new Site-Layout. I like it! More white, more light :)

I think you already know this bug: passthru() does not execute all commands in a 
*.bat-File (and does not execute all commands included directly like

 $PassThru = "C:\\_\\bladeenc.exe -q -quiet C:\\_\\sound.wav C:\\_\\sound.mp3";
 System($PassThru);
 Exec($PassThru);
 PassThru($PassThru);
).

I used passthru already with success on my Win2000-Platform with php 4.04 and MS 
Information Server (both german, no Service-Packages). But bladeenc.exe and 
mp3enc31.exe cannot be executed 
(mp3enc31 hangs).

Thanks for any help, suggestion, infos.

- Or do you need further Details about the bug?

test.php-


test





$PassThru = "C:\\_\\bladeenc.exe -q -quiet C:\\_\\sound.wav C:\\_\\sound.mp3";
$PassThru = "C:\\_\\enc.bat";
//  $PassThru = "C:\\Mp3.exe -br 32000 -if C:\\1253.wav -of C:\\1253.mp3";
echo $PassThru;
System($PassThru);
Exec($PassThru);
PassThru($PassThru);
phpinfo();



test.php-

enc.bat-
dir c:\ > c:\_\dir1
attrib -a c:\_\dir1
bladeenc.exe -q -quiet c:\_\sound.wav c:\_\sound.mp3
dir c:\ > c:\_\dir2
enc.bat-



-- 
Edit Bug report at: http://bugs.php.net/?id=9892&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9893: Wrong args in xpath_ functions makes apache crash

[jw]

From: [EMAIL PROTECTED]
Operating system: Windows 2000 SP1
PHP version:  4.0.4pl1
PHP Bug Type: Reproduceable crash
Bug description:  Wrong args in xpath_ functions makes apache crash

System: Windows 2000 SP1
Server: Apache 1.3.14 
PHP:4.0.4pl1 as module, php_domxml.dll extension

both these lines will crash Apache:

xpath_new_context($nothing);
xpath_eval($foo,$bar);



-- 
Edit Bug report at: http://bugs.php.net/?id=9893&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9894: Fatal error: Call to undefined function: ora_logon() in e:\web\root\index.php o

[i95lgg]

From: [EMAIL PROTECTED]
Operating system: WNT
PHP version:  4.0.4pl1
PHP Bug Type: MySQL related
Bug description:  Fatal error: Call to undefined function: ora_logon() in 
e:\web\root\index.php o




-- 
Edit Bug report at: http://bugs.php.net/?id=9894&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9895: Fatal error: Call to undefined function: ora_logon() in e:\web\root\index.php o

[i95lgg]

From: [EMAIL PROTECTED]
Operating system: WNT
PHP version:  4.0.4pl1
PHP Bug Type: Oracle related
Bug description:  Fatal error: Call to undefined function: ora_logon() in 
e:\web\root\index.php o




-- 
Edit Bug report at: http://bugs.php.net/?id=9895&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9896: segfaults at $xmldoc->add_root("root");

[chregu]

From: [EMAIL PROTECTED]
Operating system: Linux 2.4.2
PHP version:  4.0 Latest CVS (21/03/2001)
PHP Bug Type: DOM XML related
Bug description:  segfaults at $xmldoc->add_root("root");

Reproduce with:

$xmldoc = domxml_new_xmldoc('1.0');
domxml_add_root($xmldoc,"bla");

Configure

./configure --with-config-file-path=/usr/local/apache/conf  --with-zlib  --with-mysql  
--with-sablot --with-apxs=/usr/local/apache/bin/apxs --enable-versioning 
--with-dom=/opt/gnome

libxml2-2.3.3





-- 
Edit Bug report at: http://bugs.php.net/?id=9896&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Ben Mansell]

On Tue, 20 Mar 2001, Jani Taskinen wrote:

> On Tue, 20 Mar 2001, Andi Gutmans wrote:
>
> >At 08:32 PM 3/20/2001 +0100, Derick Rethans wrote:
> >>On Tue, 20 Mar 2001, Andi Gutmans wrote:
> >>
> >> > andi  Tue Mar 20 10:13:21 2001 EDT
> >> >
> >> >   Added files: (Branch: PHP_4_0_5)
> >> > /php4/sapi/fastcgiCREDITS Makefile.in README.FastCGI config.m4
> >> >   fastcgi.c php.sym php_fastcgi.h
> >> >   Log:
> >> >   - MFH
> >>
> >>erhm, I thought that during the Release Process no new things were being
> >>added
> >
> >The SAPI extension was never used by anyone before so there's no harm in
> >adding it (this is not changing/patching existing functionality).
> >It does make two changes to two build files but I took a very close look at
> >them and it doesn't seem like they can cause us problems.
>
> Still, it's against the rules.. :) And the config.m4 for it
> isn't..hmm..optimized.

Improvements are welcome... I'm no expert in the build system so theres
no surprises that its far from optimized.

Ben


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9897: scripts fail with error "Fatal error: Unable to create Java Virtual Machine"

[robin]

From: [EMAIL PROTECTED]
Operating system: Win98
PHP version:  4.0.4pl1
PHP Bug Type: Java related
Bug description:  scripts fail with error "Fatal error: Unable to create Java Virtual 
Machine"

The following:

  $system = new Java("java.lang.System");
  print("Java version: " .  $system->getProperty("java.version") .  "\n");
  $formatter = new Java("java.text.SimpleDateFormat", ",  dd,  'at' 
h:mm:ss a ");
  print($formatter->format(new Java("java.util.Date")) . "\n");

produces the error "Unable to create Java Virtual Machine in xyz.php on line XX" under 
PHP 4.0.5RC1 as well as the latest 4.0.4 off the php.net site.

my php.ini section is:

extension=php_java.dll
java.library.path = 
"C:\Inetpub\php\extensions;C:\Inetpub\jdk-1.3\jre\bin;C:\Inetpub\jdk-1.3\jre\lib;C:\Inetpub\jdk-1.3\lib"
java.library = C:\Inetpub\jdk-1.3\jre\bin\classic\jvm.dll
java.class.path = "C:\Inetpub\php\extensions\php_java.jar"
java.home = 
"C:\Inetpub\jdk-1.3\bin;C:\Inetpub\jdk-1.3\jre\bin;C:\Inetpub\jdk-1.3\jre\lib;C:\Inetpub\jdk-1.3\lib"

Im using J2SDK 1.3

The script actually works the first few times (the ammount of times varies) but then 
continuously fails. I've seen numerous reports of people with the same problem on 
http://www.phpbuilder.net

Installing an another machine with the same config, reproduces the same error.

It also appears to be somewhat related to bug # 6617 
(http://www.php.net/bugs.php?id=6617) and # 6925 (http://www.php.net/bugs.php?id=6925)

Are there any plans to tackle these issues?

Robin


-- 
Edit Bug report at: http://bugs.php.net/?id=9897&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Sascha Schumann]

> In my humble opinion (humility is a virtue), new modules are fine to add
> while in the release process, as long as there's at least one RC after
> them, to ensure they don't mess up the build or anything trivial like
> that.

Oh, messing up the build is a trivial thing?

> It takes 2-3 months between each and every release, and it'd be a
> shame for the new module author to receive wide exposure and feedback for
> his new code.

As the Midgard extension recently showed, a single line in an
extension can break everything else.  And it can easily go
unnoticed, especially if it is not reviewed by experienced
people.

All new modules can gain wide exposure by distributing them
separately.  They don't need to be in our tree, and
they especially don't need to be added during the release
process.  It is not worth the risk.

So few people have asked for the FastCGI module during the
last two years that I doubt that it was necessary to push it
into 4.0.5.

> In my opinion, the CVS rules should be changed to reflect
> that, just to make Jani happy, or we'd stay outlaws in his mind forever :)

The CVS rules are fine as they are.

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9895 Updated: Fatal error: Call to undefined function: ora_logon() in e:\web\root\index.php o

[derick]

ID: 9895
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: Oracle related
Assigned To: 
Comments:

Submitted twice

Previous Comments:
---

[2001-03-21 06:07:49] [EMAIL PROTECTED]


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9895&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] ImageMagick module for PHP

[Mike Robinson]

Rasmus Lerdorf writes:

> Because it didn't work, and the ImageMagick library is absolutely
> horrible.  Have a look at the Imlib2 extension.
>
> -Rasmus

I surprised imlib2 hasn't made it into the php source.
It is quite nice.

Perhaps its time it graduated. :)

.mike



> On Wed, 21 Mar 2001, [iso-8859-1] Ragnar Kjørstad wrote:
>
> > Hi
> >
> > I see there is a Image Magick module for php3 but not php4.
> > Why was it removed?
> >
> > Is there any work in progress for reimplementing it?
> > (we need it badly, and will considder joining the development)


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] config.m4 file

[Marc Boeren]

Hi!

Just thought I'ld mention that the config.m4 file needs to be in Unix
fileformat, not PC (different CRLF...)
It took me some time to figure this out, ./configure just returned 
: command not found

Sometimes it is quite annoying to be working with both Windows and Linux
boxes.
Sorry, had to get that off my chest!

Cheerio, Marc.
(BTW, could someone add this to the README.SELF-CONTAINED-EXTENSIONS file or
some other documentation? It would help some people, I feel (would've helped
me! :-))

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Zeev Suraski]

At 13:10 21/3/2001, Sascha Schumann wrote:
> > In my humble opinion (humility is a virtue), new modules are fine to add
> > while in the release process, as long as there's at least one RC after
> > them, to ensure they don't mess up the build or anything trivial like
> > that.
>
> Oh, messing up the build is a trivial thing?

Yes, it is.  Non trivial things are things that are difficult to find, 
which require long and thorough testing, such as changes to core API 
functions or very common modules.  Figuring whether the build works or not 
is trivial.

> > It takes 2-3 months between each and every release, and it'd be a
> > shame for the new module author to receive wide exposure and feedback for
> > his new code.
>
> As the Midgard extension recently showed, a single line in an
> extension can break everything else.  And it can easily go
> unnoticed, especially if it is not reviewed by experienced
> people.

Easily unnoticed?  I beg to differ.  As soon as someone tried to build it, 
it failed.  That's why it's trivial, and that's why it's relatively safe to 
do it even while RC's are going.  The rule of 'dont break the CVS build' is 
crucial, and should be followed especially with RC's.  But the worst case 
situation of adding a new module is a broken build, which is noticed 
immediately, and thus is not dangerous.

> All new modules can gain wide exposure by distributing them
> separately.  They don't need to be in our tree, and
> they especially don't need to be added during the release
> process.  It is not worth the risk.

The risk is pretty much non existent, as I demonstrated.  Especially with a 
SAPI module, what you say isn't true.

> So few people have asked for the FastCGI module during the
> last two years that I doubt that it was necessary to push it
> into 4.0.5.

Zeus moved its recommendation from using the native ISAPI/Zeus module to 
using FastCGI, because of instability.  So you can expect FastCGI to be 
more popular.

> > In my opinion, the CVS rules should be changed to reflect
> > that, just to make Jani happy, or we'd stay outlaws in his mind forever :)
>
> The CVS rules are fine as they are.

Yes, so says you.  But I beg to differ.

Zeev


--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9898: gd and mck fail to link but did in 4.0.4pl1

[wez]

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.0 Latest CVS (21/03/2001)
PHP Bug Type: Compile Problem
Bug description:  gd and mck fail to link but did in 4.0.4pl1

the final stage of the build says:
*** Warning: This library needs some functionality provided by -lgd.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.

*** Warning: This library needs some functionality provided by -lmckcrypto.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.

It is correct - I do not have shared versions of these libraries, but previous 
versions of PHP linked correctly.
PHP 4.0.4pl1 still compiles and links, and I'm pretty sure CVS worked about a week ago.

--Wez.


-- 
Edit Bug report at: http://bugs.php.net/?id=9898&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9898 Updated: gd and mck fail to link but did in 4.0.4pl1

[wez]

ID: 9898
Updated by: wez
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Duplicate
Bug Type: Compile Problem
Assigned To: 
Comments:

Sorry - forgot some info which is in the other report.
I'm having B/W problems so the bug system is reacting slowly for me...

Previous Comments:
---

[2001-03-21 07:28:17] [EMAIL PROTECTED]
the final stage of the build says:
*** Warning: This library needs some functionality provided by -lgd.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.

*** Warning: This library needs some functionality provided by -lmckcrypto.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.

It is correct - I do not have shared versions of these libraries, but previous 
versions of PHP linked correctly.
PHP 4.0.4pl1 still compiles and links, and I'm pretty sure CVS worked about a week 
ago.

--Wez.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9898&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9898 Updated: gd and mck fail to link but did in 4.0.4pl1

[wez]

ID: 9898
Updated by: wez
Reported By: [EMAIL PROTECTED]
Old-Status: Duplicate
Status: Open
Bug Type: Compile Problem
Assigned To: 
Comments:

Weird - can't find my duplicate report, so reopened this one.

I'm having problems with the bug system - it's slow to react and seems to hang.

Anyway, I left this information out:

/bin/sh /home/wez/source/phpbuild/libtool --silent --mode=link gcc  -I. 
-I/home/wez/source/phpbuild/ -I/home/wez/source/phpbuild/main 
-I/home/wez/source/phpbuild -I/usr/include/apache -I/home/wez/source/phpbuild/Zend 
-I/usr/local/include -I/usr/local/mck-3.2.0.3-linux//c-api -I/usr/include/freetype 
-I/usr/include/gd -I/usr/include/imap -I/usr/include/mysql -I/usr/local/include/pspell 
-I/home/CLIENTWEB/sophosantivirus/sav_if 
-I/home/wez/source/phpbuild/ext/xml/expat/xmltok 
-I/home/wez/source/phpbuild/ext/xml/expat/xmlparse -I/home/wez/source/phpbuild/TSRM  
-DEAPI_MM -DLINUX=2 -DMOD_SSL=206105 -DUSE_HSREGEX -DEAPI -DUSE_EXPAT -DSUPPORT_UTF8 
-DXML_BYTE_ORDER=12 -g -O2   -o libphp4.la -rpath /home/wez/source/phpbuild/libs 
-avoid-version -L/usr/local/lib -L/usr/local/mck-3.2.0.3-linux//c-api/lib 
-L/usr/lib/mysql  -R /usr/local/lib -R /usr/local/mck-3.2.0.3-linux//c-api/lib -R 
/usr/lib/mysql stub.lo  Zend/libZend.la sapi/apache/libsapi.la main/libmain.la 
regex/libregex.la ext/bz2/libbz2.la ext/calendar/libcalendar.la ext/curl/libcurl.la 
ext/cybercash/libcybercash.la ext/dbg/libdbg.la ext/ftp/libftp.la ext/gd/libgd.la 
ext/gettext/libgettext.la ext/iconv/libiconv.la ext/imap/libimap.la 
ext/jstring/libjstring.la ext/ldap/libldap.la ext/mailparse/libmailparse.la 
ext/mbregex/libmbregex.la ext/mhash/libmhash.la ext/mysql/libmysql.la 
ext/pcre/libpcre.la ext/posix/libposix.la ext/pspell/libpspell.la ext/savi/libsavi.la 
ext/session/libsession.la ext/shmop/libshmop.la ext/sockets/libsockets.la 
ext/standard/libstandard.la ext/sysvsem/libsysvsem.la ext/sysvshm/libsysvshm.la 
ext/wddx/libwddx.la ext/xml/libxml.la ext/yp/libyp.la ext/zlib/libzlib.la 
TSRM/libtsrm.la -lpam -lsavi -lc-client -ldl -lz -lpspell -lmysqlclient -lmhash -lldap 
-llber -lttf -lz -lpng -lgd -lmckcrypto -lcurl -lbz2 -lresolv -lm -ldl -lcrypt -lnsl 
-lresolv


Previous Comments:
---

[2001-03-21 07:38:21] [EMAIL PROTECTED]
Sorry - forgot some info which is in the other report.
I'm having B/W problems so the bug system is reacting slowly for me...

---

[2001-03-21 07:28:17] [EMAIL PROTECTED]
the final stage of the build says:
*** Warning: This library needs some functionality provided by -lgd.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.

*** Warning: This library needs some functionality provided by -lmckcrypto.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.

It is correct - I do not have shared versions of these libraries, but previous 
versions of PHP linked correctly.
PHP 4.0.4pl1 still compiles and links, and I'm pretty sure CVS worked about a week 
ago.

--Wez.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9898&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Zeev Suraski]

No disrespect for the config.m4, it's not all that important if it's 
optimized or not :)

At 13:09 21/3/2001, Ben Mansell wrote:
>On Tue, 20 Mar 2001, Jani Taskinen wrote:
>
> > On Tue, 20 Mar 2001, Andi Gutmans wrote:
> >
> > >At 08:32 PM 3/20/2001 +0100, Derick Rethans wrote:
> > >>On Tue, 20 Mar 2001, Andi Gutmans wrote:
> > >>
> > >> > andi  Tue Mar 20 10:13:21 2001 EDT
> > >> >
> > >> >   Added files: (Branch: PHP_4_0_5)
> > >> > /php4/sapi/fastcgiCREDITS Makefile.in README.FastCGI 
> config.m4
> > >> >   fastcgi.c php.sym php_fastcgi.h
> > >> >   Log:
> > >> >   - MFH
> > >>
> > >>erhm, I thought that during the Release Process no new things were being
> > >>added
> > >
> > >The SAPI extension was never used by anyone before so there's no harm in
> > >adding it (this is not changing/patching existing functionality).
> > >It does make two changes to two build files but I took a very close 
> look at
> > >them and it doesn't seem like they can cause us problems.
> >
> > Still, it's against the rules.. :) And the config.m4 for it
> > isn't..hmm..optimized.
>
>Improvements are welcome... I'm no expert in the build system so theres
>no surprises that its far from optimized.
>
>Ben
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Sascha Schumann]

> Yes, it is.  Non trivial things are things that are difficult to find,
> which require long and thorough testing, such as changes to core API
> functions or very common modules.  Figuring whether the build works or not
> is trivial.

That might be true for a single build.  We support dozens of
platforms and figuring out whether a change breaks something
on one particular platform is not as simple as you obviously
assume.

> > As the Midgard extension recently showed, a single line in an
> > extension can break everything else.  And it can easily go
> > unnoticed, especially if it is not reviewed by experienced
> > people.
>
> Easily unnoticed?  I beg to differ.

Zeev, there is a difference between the terms 'will' and
'can'.  I've used the latter.

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Zeev Suraski]

At 15:50 21/3/2001, Sascha Schumann wrote:
> > Yes, it is.  Non trivial things are things that are difficult to find,
> > which require long and thorough testing, such as changes to core API
> > functions or very common modules.  Figuring whether the build works or not
> > is trivial.
>
> That might be true for a single build.  We support dozens of
> platforms and figuring out whether a change breaks something
> on one particular platform is not as simple as you obviously
> assume.

I don't think that there would be a real life situation in which a new 
module would break a build under one platform, and won't under another 
platform, without you actually using the module.  The author has to be 
exceptionally 'talented' to achieve that.

> > > As the Midgard extension recently showed, a single line in an
> > > extension can break everything else.  And it can easily go
> > > unnoticed, especially if it is not reviewed by experienced
> > > people.
> >
> > Easily unnoticed?  I beg to differ.
>
> Zeev, there is a difference between the terms 'will' and
> 'can'.  I've used the latter.

I know, and as I said, I disagree.  I don't think it can go unnoticed in 
the further RC.

Zeev


--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Sascha Schumann]

> I don't think that there would be a real life situation in which a new
> module would break a build under one platform, and won't under another
> platform, without you actually using the module.  The author has to be
> exceptionally 'talented' to achieve that.

The config.m4 just has to reach a certain complexity to
become incomprehensible.  I suggest reading ext/gd/config.m4
for starters.

> I know, and as I said, I disagree.  I don't think it can go unnoticed in
> the further RC.

Ah, of course.  Just as newly introduced bugs in the code are
catched by further RCs..

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Zeev Suraski]

At 16:20 21/3/2001, Sascha Schumann wrote:
> > I don't think that there would be a real life situation in which a new
> > module would break a build under one platform, and won't under another
> > platform, without you actually using the module.  The author has to be
> > exceptionally 'talented' to achieve that.
>
> The config.m4 just has to reach a certain complexity to
> become incomprehensible.  I suggest reading ext/gd/config.m4
> for starters.

As you may know, new scripts don't tend to be born with nuclear simulations 
as their config.m4, as the gd extension grew to have during the years.

> > I know, and as I said, I disagree.  I don't think it can go unnoticed in
> > the further RC.
>
> Ah, of course.  Just as newly introduced bugs in the code are
> catched by further RCs..

No, not even similarly.

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Sascha Schumann]

> As you may know, new scripts don't tend to be born with nuclear simulations
> as their config.m4, as the gd extension grew to have during the years.

"don't tend" does not preclude the existance of such modules
in the future.

Guys, please play by the rules which are laid down in
RELEASE_PROCESS.  Further decreasing the quality of PHP
releases doesn't help anyone and just makes us look bad.

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Bug #9899: POST Upload corrupted with Content-type string

[tkircht]

From: [EMAIL PROTECTED]
Operating system: RedHat/Linux 2.2.16-22
PHP version:  3.0.17
PHP Bug Type: Misbehaving function
Bug description:  POST Upload corrupted with Content-type string

I am using PHP 3.0.18-1.6 on a RedHat system.I am using the following script to upload 
files to the server:

[...]

 

  

Name: 
   

  

 
[...] 

==
And this for copying the file to the harddisk:
==
  

  \n",$username);
printf ("FileName: %s \n",$userfile_name);
printf ("FileSize: %s Bytes\n",$userfile_size);
printf ("FileType: %s \n",$userfile_type);
 
if ( $userfile_size == 0 )
{
printf ("Achtung! Datei ist größer als 5MB - Upload 
verweigert");
};
 
$category=trim($category);
$username=trim($username);
 
printf ("TmpFileName: %s \n",$userfile);
printf ("Category: %s \n",$category);
$ext=substr($userfile_name,-3,3);
$newfilename=sprintf("%s/%s.%s",$category,$username,$ext);
if ( ! file_exists($category)){
   umask(0);
   mkdir($category,04770);
  }
if (copy($userfile,$newfilename))
{
chmod($newfilename,0775);
printf("%s wurde erfolgreich empfangen und als %s 
abgelegt!",$userfile_name,$category,$newfilename);
}
else
{
printf("%s konnte nicht als %s-%s abgelegt 
werden",$userfile_name,$category,$newfilename);
};
?>
 

  
  


The resulting files contain

[root@coimbra Studenten]# head -2 Technische_Physik/me.wav
Content-Type: audio/wav
 
[root@coimbra Studenten]#

as the first two lines, making them unusable for binary types.

the $userfile_type variable is empty.

This used to work fine with PHP 3.0.14.





-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Thies C. Arntzen]

On Wed, Mar 21, 2001 at 03:30:58PM +0100, Sascha Schumann wrote:
> 
> Guys, please play by the rules which are laid down in
> RELEASE_PROCESS.  Further decreasing the quality of PHP
> releases doesn't help anyone and just makes us look bad.

i fully agree to sascha. plus i see no real reason to include
a new module once we are in "release-process". new modules
are by default not "producition-stable" so why hurry to
include them in a "official-release"? 

the no. 1 (and maybe only goal) for a release should be
stability and well tested functionality IMHO.

tc


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Hartmut Holzgraefe]

Sascha Schumann wrote:
> Guys, please play by the rules which are laid down in
> RELEASE_PROCESS.  Further decreasing the quality of PHP
> releases doesn't help anyone and just makes us look bad.
 
yes, that's it, let's play by the rules during a RC cycle or
don't have rules at all

rules for release cycles might be changed between RC cycles,
but should definetly be applied unchanged while in use



-- 
Hartmut Holzgraefe  [EMAIL PROTECTED]  http://www.six.de  +49-711-99091-77 

Besuchen Sie uns auf der CeBIT 2001 - in Halle 6 Stand F62/4

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] LDAP module: ldap_read_entries not compatible with binary attributes

[Leo]

Hello

I just got  into troubles when using ldap_read_entries() on binary
attributes, i my program a usercertificate  :
On binary data, ldap_read_entries()  returns garbages whenever it meets
a NULL character.

I know the longer way to do it, using a sequence of ldap_first_entry(
), ldap_first_attribute( ),  ldap_get_values_len,
ldap_next_attribute().
but this is a pain for the lazy programmers.

A solution would be an extra parameter or an option to instruct
ldap_read_entries()  to use ldap_get_values_len() instead of
ldap_get_values :
ldap.c lines 1018-1020:

while (attribute != NULL) {
   ldap_value = ldap_get_values(ldap, ldap_result_entry, attribute);
   num_values = ldap_count_values(ldap_value);

Does anyone see a better way to fix that ?

--Leo West



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Zeev Suraski]

At 16:44 21/3/2001, Hartmut Holzgraefe wrote:
>Sascha Schumann wrote:
> > Guys, please play by the rules which are laid down in
> > RELEASE_PROCESS.  Further decreasing the quality of PHP
> > releases doesn't help anyone and just makes us look bad.
>
>yes, that's it, let's play by the rules during a RC cycle or
>don't have rules at all
>
>rules for release cycles might be changed between RC cycles,
>but should definetly be applied unchanged while in use

I definitely don't agree with this definitely.  A good thing about 
opensource projects is that there aren't committees and thick rule books 
that move and act at the speed of a dinosaur.  When it begins to look that 
way, you know you're in the wrong direction.
It doesn't mean that we shouldn't have rules, but I'll never support rules 
such as 'dont debate/change the rules while [ANYTHING]'.  If the rules are 
broken, or there was lacking vision when we authored them, it should be 
fixed on the spot.

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Sascha Schumann]

> I definitely don't agree with this definitely.  A good thing about
> opensource projects is that there aren't committees and thick rule books
> that move and act at the speed of a dinosaur.  When it begins to look that
> way, you know you're in the wrong direction.

OpenSource does not mean careless committers and bug-riddled
software.  OpenSource software can excel in code quality and
stableness.

Your personal goal seems to differ from that target.  I think
that is a pity.

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] This won't get us nowhere (WAS: cvs: php4(PHP_4_0_5) /sapi/fastcgi)

[Cynic]

Sascha & Zeev,

May I please ask you to calm down a bit? Flamewars and insults
won't help anyone.

I think you both could use a few minutes to take your breath.


At 16:38 21.3. 2001, Zeev Suraski wrote the following:
-- 
>At 17:15 21/3/2001, Sascha Schumann wrote:
>>> I definitely don't agree with this definitely.  A good thing about
>>> opensource projects is that there aren't committees and thick rule books
>>> that move and act at the speed of a dinosaur.  When it begins to look that
>>> way, you know you're in the wrong direction.
>>
>>OpenSource does not mean careless committers and bug-riddled
>>software.  OpenSource software can excel in code quality and
>>stableness.
>>
>>Your personal goal seems to differ from that target.  I think
>>that is a pity.
>
>Your argumentative tone is also a pity.
>
>As for the issue at hand, we differ greatly at the amount of importance we attribute 
>to considering rules as if they were God-given.  I care about PHP's quality a lot, 
>quite before you were even a contributor to the project.  I'm not coming to downplay 
>your caring, but I'm not sure what makes you think you can downplay mine.
>
>The fact that you see what I say as if opensource software means bug-riddled software 
>or careless committers still doesn't mean that's what I'm saying, and obviously (as 
>I'm sure you know deep inside), it's not.  That's just your binary way of looking at 
>things, which is thankfully not shared by most people.  I stand completely behind 
>what I said, but obviously not behind your summary of what I said.
>
>The bottom line is that, as I said, the trick in good opensource software is taking 
>calculated risks, and mixing agility with quality assurance.  One can look through 
>your binary glasses, and then it's either complete lack of quality, or complete lack 
>of risks, and one can look with reasonable experienced eyes and strive to get to the 
>right mixture.  I, for one, don't enjoy looking through these binary glasses.
>
>Zeev
>
>
>-- 
>PHP Quality Assurance Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]
--end of quote-- 


[EMAIL PROTECTED]
-
And the eyes of them both were opened and they saw that their files
were world readable and writable, so they chmoded 600 their files.
- Book of Installation chapt 3 sec 7 


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: This won't get us nowhere (WAS: cvs: php4(PHP_4_0_5) /sapi/fastcgi)

[Zeev Suraski]

I'm completely agree (my breath is fine, though :)

Zeev

At 17:52 21/3/2001, Cynic wrote:
>Sascha & Zeev,
>
>May I please ask you to calm down a bit? Flamewars and insults
>won't help anyone.
>
>I think you both could use a few minutes to take your breath.
>
>
>At 16:38 21.3. 2001, Zeev Suraski wrote the following:
>--
> >At 17:15 21/3/2001, Sascha Schumann wrote:
> >>> I definitely don't agree with this definitely.  A good thing about
> >>> opensource projects is that there aren't committees and thick rule books
> >>> that move and act at the speed of a dinosaur.  When it begins to look 
> that
> >>> way, you know you're in the wrong direction.
> >>
> >>OpenSource does not mean careless committers and bug-riddled
> >>software.  OpenSource software can excel in code quality and
> >>stableness.
> >>
> >>Your personal goal seems to differ from that target.  I think
> >>that is a pity.
> >
> >Your argumentative tone is also a pity.
> >
> >As for the issue at hand, we differ greatly at the amount of importance 
> we attribute to considering rules as if they were God-given.  I care 
> about PHP's quality a lot, quite before you were even a contributor to 
> the project.  I'm not coming to downplay your caring, but I'm not sure 
> what makes you think you can downplay mine.
> >
> >The fact that you see what I say as if opensource software means 
> bug-riddled software or careless committers still doesn't mean that's 
> what I'm saying, and obviously (as I'm sure you know deep inside), it's 
> not.  That's just your binary way of looking at things, which is 
> thankfully not shared by most people.  I stand completely behind what I 
> said, but obviously not behind your summary of what I said.
> >
> >The bottom line is that, as I said, the trick in good opensource 
> software is taking calculated risks, and mixing agility with quality 
> assurance.  One can look through your binary glasses, and then it's 
> either complete lack of quality, or complete lack of risks, and one can 
> look with reasonable experienced eyes and strive to get to the right 
> mixture.  I, for one, don't enjoy looking through these binary glasses.
> >
> >Zeev
> >
> >
> >--
> >PHP Quality Assurance Mailing List 
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >To contact the list administrators, e-mail: [EMAIL PROTECTED]
>--end of quote--
>
>
>[EMAIL PROTECTED]
>-
>And the eyes of them both were opened and they saw that their files
>were world readable and writable, so they chmoded 600 their files.
> - Book of Installation chapt 3 sec 7

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: This won't get us nowhere (WAS: cvs: php4(PHP_4_0_5) /sapi/fastcgi)

[Zeev Suraski]

At 17:49 21/3/2001, Zeev Suraski wrote:
>I'm completely agree (my breath is fine, though :)

I, even :)

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] HAVE_INT_8_16_32

[Ben Mansell]

The libMySQL code has got references to a 'HAVE_INT_8_16_32' in an
#ifdef, but its never set anywhere. This is a problem on AIX operating
systems, where types like 'int8', 'int16' and so on are defined in
/usr/include/sys/

I'd like to put a patch in to actually define HAVE_INT_8_16_32 if its
needed, but I've got no idea where/how to do such a thing. Can anyone
help, please?

Cheers,
Ben


-- 
Ben Mansell, <[EMAIL PROTECTED]>   Zeus Technology Ltd
Download the world's fastest webserver!   Universally Serving the Net
T:+44(0)1223 525000 F:+44(0)1223 525100   http://www.zeus.com
Zeus House, Cowley Road, Cambridge, CB4 0ZT, ENGLAND


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Bug #1705 Updated: easter_date() and easter_days()

[Pierre François]

Hello,
 
I'm trying to use the easter_date() function of 
PHP, but I receive a fatal error saying the function is not defined. Do you know 
what I have to do for fixing this?
 
Tahnk you.
--Pierre 
FrançoisTervuursevest 123/243001 Leuven (Belgium)+32 16 23 21 
52 

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Sascha Schumann]

> The bottom line is that, as I said, the trick in good opensource software
> is taking calculated risks, and mixing agility with quality assurance.  One
> can look through your binary glasses, and then it's either complete lack of
> quality, or complete lack of risks, and one can look with reasonable
> experienced eyes and strive to get to the right mixture.  I, for one, don't
> enjoy looking through these binary glasses.

Then please start explaining what the right mixture is.
Apparently, we have not found the right mixture yet, unless
of course, patchlevel releases are part of that Great Plan.

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Zeev Suraski]

At 17:15 21/3/2001, Sascha Schumann wrote:
> > I definitely don't agree with this definitely.  A good thing about
> > opensource projects is that there aren't committees and thick rule books
> > that move and act at the speed of a dinosaur.  When it begins to look that
> > way, you know you're in the wrong direction.
>
> OpenSource does not mean careless committers and bug-riddled
> software.  OpenSource software can excel in code quality and
> stableness.
>
> Your personal goal seems to differ from that target.  I think
> that is a pity.

Your argumentative tone is also a pity.

As for the issue at hand, we differ greatly at the amount of importance we 
attribute to considering rules as if they were God-given.  I care about 
PHP's quality a lot, quite before you were even a contributor to the 
project.  I'm not coming to downplay your caring, but I'm not sure what 
makes you think you can downplay mine.

The fact that you see what I say as if opensource software means 
bug-riddled software or careless committers still doesn't mean that's what 
I'm saying, and obviously (as I'm sure you know deep inside), it's 
not.  That's just your binary way of looking at things, which is thankfully 
not shared by most people.  I stand completely behind what I said, but 
obviously not behind your summary of what I said.

The bottom line is that, as I said, the trick in good opensource software 
is taking calculated risks, and mixing agility with quality assurance.  One 
can look through your binary glasses, and then it's either complete lack of 
quality, or complete lack of risks, and one can look with reasonable 
experienced eyes and strive to get to the right mixture.  I, for one, don't 
enjoy looking through these binary glasses.

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9900: sem_remove or similar missing

[t . stinner]

From: [EMAIL PROTECTED]
Operating system: all
PHP version:  4.0.4pl1
PHP Bug Type: Feature/Change Request
Bug description:  sem_remove or similar missing

I miss a function sem_remove or similar which i can use to remove a
semaphore completely. 




-- 
Edit Bug report at: http://bugs.php.net/?id=9900&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9901: When running the make it fails

[dolivier]

From: [EMAIL PROTECTED]
Operating system: Digital Unix 5.1
PHP version:  4.0.4pl1
PHP Bug Type: Compile Failure
Bug description:  When running the make it fails 

Basically we run the first 7 or 8 steps in the install instructions, but when we go 
and run amke we get the following: list' previously declared here
mips-tfile, /tmp/cc8HgmOE.s:8 Invalid .stabs/.stabn directive, value not found
line:#.stabs "/usr/local/php-4.0.4pl1/Zend/",100,0,0,$Ltext0

mips-tfile, /tmp/cc8HgmOE.s:9 Invalid .stabs/.stabn directive, value not found
line:#.stabs "zend_sprintf.c",100,0,0,$Ltext0

mips-tfile, /tmp/cc8HgmOE.s:194 Segmentation fault
line:#.stabs "zend_write_func_t:t269=253",128,0,246,0

*** Exit 1
Stop.
*** Exit 1
Stop.

Any guess as to why I can' get this to compile on my machine.



-- 
Edit Bug report at: http://bugs.php.net/?id=9901&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] Bug #1705 Updated: easter_date() and easter_days()

[Chris Newbill]

First, you must meet these requirements.
 
PHP 3>= 3.0.9, PHP 4 >= 
4.0RC2
PHP was compiled with 
'--enable-calendar'.
 
Chris

  -Original Message-From: Pierre François 
  [mailto:[EMAIL PROTECTED]]Sent: Wednesday, 21 March, 2001 9-05 
  aMTo: [EMAIL PROTECTED]Subject: Re: [PHP-DEV] Bug 
  #1705 Updated: easter_date() and easter_days()
  Hello,
   
  I'm trying to use the easter_date() function of 
  PHP, but I receive a fatal error saying the function is not defined. Do you 
  know what I have to do for fixing this?
   
  Tahnk you.
  --Pierre 
  FrançoisTervuursevest 123/243001 Leuven (Belgium)+32 16 23 21 
  52 

[PHP-DEV] CORBA/PHP

[Nick Loman]

Hi

I've got a fairly urgent requirement to get Satellite working properly on
my PHP 4.0.4pl1 system and can't get in touch with David Eriksson. Has
anyone had luck with the setup, specifically accessing objects through 
IIOP over TCP/IP who would be prepared to share configs with me? I am
compiled OK and the mod is installed but it seg faults each time with
glib errors in the log file whenever I call new Object.

Or if anyone knows where David is likely to be I would very much 
appreciate being put in touch with him.

Thanks!

Nick.


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] 4.0.5RC1 crash...

[Dan Kalowsky]

Follow up on the earlier reporting of having memory issues to 4.0.5RC1.

We've been able to reproduce the problem once again.  Although it seems
to be only happening after EXTREMELY long periods of time and continuous
heavy usage during that time.  Currently I'm not able to point exactly
to any specific area causing it (I know the script, but the line is
unknown) so let's see what I can give you to help debug this a bit
further

This time around we've got a bit more information for your enjoyment
though...
Snippits from the /var/log/httpd-error.log file:

[Fri Mar 16 09:42:37 2001] [notice] SIGHUP received.  Attempting to
restart
[Fri Mar 16 09:42:38 2001] [notice] Apache/1.3.17 (Unix) mod_perl/1.24
PHP/4.0.5RC1 configured -- resuming normal operations
zend_hash.c(202) :  Freeing 0x083066E4 (20 bytes),
script=/usr/local/www/data/Login/users_login.php
zend_API.c(219) :  Freeing 0x08173124 (48 bytes),
script=/usr/local/www/data/Login/users_login.php
zend_API.c(208) : Actual location (location was relayed)
zend_hash.c(202) :  Freeing 0x0835E6E4 (20 bytes),
script=/usr/local/www/data/Login/users_login.php
zend_API.c(219) :  Freeing 0x081E37A4 (48 bytes),
script=/usr/local/www/data/Login/users_login.php
zend_API.c(208) : Actual location (location was relayed)
[Fri Mar 16 17:13:05 2001] [error] [client 172.16.64.5] File does not
exist: /usr/local/www/data/interactive/internet/index.html


Yet again even more.  from Friday March 19th
zend_hash.c(202) :  Freeing 0x081B9E24 (20 bytes),
script=/usr/local/www/data/Login/users_login.php
zend_API.c(219) :  Freeing 0x081B86A4 (48 bytes),
script=/usr/local/www/data/Login/users_login.php
zend_API.c(208) : Actual location (location was relayed)
zend_hash.c(202) :  Freeing 0x081A8E24 (20 bytes),
script=/usr/local/www/data/Login/users_login.php
zend_API.c(219) :  Freeing 0x0819F5A4 (48 bytes),
script=/usr/local/www/data/Login/users_login.php
zend_API.c(208) : Actual location (location was relayed)
zend_hash.c(202) :  Freeing 0x081BAE24 (20 bytes),
script=/usr/local/www/data/Login/users_login.php
zend_API.c(219) :  Freeing 0x081A96A4 (48 bytes),
script=/usr/local/www/data/Login/users_login.php
zend_API.c(208) : Actual location (location was relayed)
zend_hash.c(202) :  Freeing 0x081B8E24 (20 bytes),
script=/usr/local/www/data/Login/users_login.php
Last leak repeated 212 times
zend_opcode.c(304) :  Freeing 0x08205024 (2100 bytes),
script=/usr/local/www/data/Login/users_login.php
Last leak repeated 1 time
./zend_language_scanner.l(1059) :  Freeing 0x0820D824 (39 bytes),
script=/usr/local/www/data/Login/users_login.php
Last leak repeated 8 times
zend_hash.c(461) :  Freeing 0x081DCBA4 (76 bytes),
script=/usr/local/www/data/Login/users_login.php
Last leak repeated 13 times
./zend_execute.c(1629) :  Freeing 0x0824B564 (24 bytes),
script=/usr/local/www/data/Login/users_login.php
zend_variables.c(117) : Actual location (location was relayed)
Last leak repeated 41 times
Last leak repeated 6 times
var.c(475) :  Freeing 0x0833AA24 (2 bytes),
script=/usr/local/www/data/Login/users_login.php
Last leak repeated 15 times
var.c(562) :  Freeing 0x0833A9A4 (12 bytes),
script=/usr/local/www/data/Login/users_login.php
Last leak repeated 16 times
session.c(501) :  Freeing 0x082529A4 (48 bytes),
script=/usr/local/www/data/Login/users_login.php
zend_API.c(188) : Actual location (location was relayed) 
session.c(500) :  Freeing 0x0833BFE4 (12 bytes),
script=/usr/local/www/data/Login/users_login.php
mod_files.c(134) :  Freeing 0x0822DFA4 (33 bytes),
script=/usr/local/www/data/Login/users_login.php
mod_files.c(209) :  Freeing 0x081BBC64 (5 bytes),
script=/usr/local/www/data/Login/users_login.php
mod_files.c(201) :  Freeing 0x08335E24 (16 bytes),
script=/usr/local/www/data/Login/users_login.php
session.c(873) :  Freeing 0x081F60A4 (33 bytes),
script=/usr/local/www/data/Login/users_login.php
zend_compile.c(1605) :  Freeing 0x083186E4 (12 bytes),
script=/usr/local/www/data/Login/users_login.php
Last leak repeated 3 times
main.c(1059) :  Freeing 0x081B9C24 (48 bytes),
script=/usr/local/www/data/home/menu_walled_garden.php



This goes on for some time, so if you want to see it all, you can find
the full version at http://www.deadmime.org/~dank/sitics-error.log 

But it also leaves an interesting spot in the middle:

---
zend_opcode.c(168) : Block 0x081ACAC0 status:
zend_variables.c(62) : Actual location (location was relayed)
Beginning:  OK (allocated on ./zend_language_scanner.l:739, 89
bytes)
  End:  Overflown (magic=0x283F791C instead of 0x2A8FCC84)
At least 4 bytes overflown
---

<. SOME TIME/BAD-FILE-REQUESTS PASSING  >

---
zend_opcode.c(168) : Block 0x08AE4B80 status:
zend_variables.c(62) : Actual location (location was relayed)
Beginning:  OK (allocated on ./zend_language_scanner.l:1152, 217
bytes)
  End:  Overflown (magic=0x283F791C inste

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Zeev Suraski]

In an attempt to fulfill Cynic's request, I'll only say that this whole 
thread began when I suggested that the release-process is modified to 
reflect that adding new modules is allowed.

Zeev

At 18:03 21/3/2001, Sascha Schumann wrote:
> > The bottom line is that, as I said, the trick in good opensource software
> > is taking calculated risks, and mixing agility with quality assurance.  One
> > can look through your binary glasses, and then it's either complete lack of
> > quality, or complete lack of risks, and one can look with reasonable
> > experienced eyes and strive to get to the right mixture.  I, for one, don't
> > enjoy looking through these binary glasses.
>
> Then please start explaining what the right mixture is.
> Apparently, we have not found the right mixture yet, unless
> of course, patchlevel releases are part of that Great Plan.
>
> - Sascha Experience IRCG
>   http://schumann.cx/http://schumann.cx/ircg

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9902: Converting to/from mysql timestamp

[mail]

From: [EMAIL PROTECTED]
Operating system: Red Hat Linux 7.x
PHP version:  4.0.4pl1
PHP Bug Type: Feature/Change Request
Bug description:  Converting to/from mysql timestamp

I propose some new functions for those of us that use PHP and mySQL together on a 
daily basis...

I would suggest a function that acts like getdate() which produces an array of time 
and date data from a mySQL timestamp (MMDDHHMMSS).

Along these lines, functions which convert between a unix timestamp and a mySQL 
timestamp would be useful.

Surely I'm not the only one that has to include my own custom functions to produce 
these results.

Having standard distribution-based versions of these functions would make my and 
others work a lot easier.


-- 
Edit Bug report at: http://bugs.php.net/?id=9902&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] 4.0.5RC1 crash...

[Zeev Suraski]

Is this a new issue in 4.0.5?  Or did the problem exist in older versions 
as well?

Zeev

At 18:44 21/3/2001, Dan Kalowsky wrote:
>Follow up on the earlier reporting of having memory issues to 4.0.5RC1.
>
>We've been able to reproduce the problem once again.  Although it seems
>to be only happening after EXTREMELY long periods of time and continuous
>heavy usage during that time.  Currently I'm not able to point exactly
>to any specific area causing it (I know the script, but the line is
>unknown) so let's see what I can give you to help debug this a bit
>further
>
>This time around we've got a bit more information for your enjoyment
>though...
>Snippits from the /var/log/httpd-error.log file:
>
>[Fri Mar 16 09:42:37 2001] [notice] SIGHUP received.  Attempting to
>restart
>[Fri Mar 16 09:42:38 2001] [notice] Apache/1.3.17 (Unix) mod_perl/1.24
>PHP/4.0.5RC1 configured -- resuming normal operations
>zend_hash.c(202) :  Freeing 0x083066E4 (20 bytes),
>script=/usr/local/www/data/Login/users_login.php
>zend_API.c(219) :  Freeing 0x08173124 (48 bytes),
>script=/usr/local/www/data/Login/users_login.php
>zend_API.c(208) : Actual location (location was relayed)
>zend_hash.c(202) :  Freeing 0x0835E6E4 (20 bytes),
>script=/usr/local/www/data/Login/users_login.php
>zend_API.c(219) :  Freeing 0x081E37A4 (48 bytes),
>script=/usr/local/www/data/Login/users_login.php
>zend_API.c(208) : Actual location (location was relayed)
>[Fri Mar 16 17:13:05 2001] [error] [client 172.16.64.5] File does not
>exist: /usr/local/www/data/interactive/internet/index.html
>
>
>Yet again even more.  from Friday March 19th
>zend_hash.c(202) :  Freeing 0x081B9E24 (20 bytes),
>script=/usr/local/www/data/Login/users_login.php
>zend_API.c(219) :  Freeing 0x081B86A4 (48 bytes),
>script=/usr/local/www/data/Login/users_login.php
>zend_API.c(208) : Actual location (location was relayed)
>zend_hash.c(202) :  Freeing 0x081A8E24 (20 bytes),
>script=/usr/local/www/data/Login/users_login.php
>zend_API.c(219) :  Freeing 0x0819F5A4 (48 bytes),
>script=/usr/local/www/data/Login/users_login.php
>zend_API.c(208) : Actual location (location was relayed)
>zend_hash.c(202) :  Freeing 0x081BAE24 (20 bytes),
>script=/usr/local/www/data/Login/users_login.php
>zend_API.c(219) :  Freeing 0x081A96A4 (48 bytes),
>script=/usr/local/www/data/Login/users_login.php
>zend_API.c(208) : Actual location (location was relayed)
>zend_hash.c(202) :  Freeing 0x081B8E24 (20 bytes),
>script=/usr/local/www/data/Login/users_login.php
>Last leak repeated 212 times
>zend_opcode.c(304) :  Freeing 0x08205024 (2100 bytes),
>script=/usr/local/www/data/Login/users_login.php
>Last leak repeated 1 time
>./zend_language_scanner.l(1059) :  Freeing 0x0820D824 (39 bytes),
>script=/usr/local/www/data/Login/users_login.php
>Last leak repeated 8 times
>zend_hash.c(461) :  Freeing 0x081DCBA4 (76 bytes),
>script=/usr/local/www/data/Login/users_login.php
>Last leak repeated 13 times
>./zend_execute.c(1629) :  Freeing 0x0824B564 (24 bytes),
>script=/usr/local/www/data/Login/users_login.php
>zend_variables.c(117) : Actual location (location was relayed)
>Last leak repeated 41 times
>Last leak repeated 6 times
>var.c(475) :  Freeing 0x0833AA24 (2 bytes),
>script=/usr/local/www/data/Login/users_login.php
>Last leak repeated 15 times
>var.c(562) :  Freeing 0x0833A9A4 (12 bytes),
>script=/usr/local/www/data/Login/users_login.php
>Last leak repeated 16 times
>session.c(501) :  Freeing 0x082529A4 (48 bytes),
>script=/usr/local/www/data/Login/users_login.php
>zend_API.c(188) : Actual location (location was relayed)
>session.c(500) :  Freeing 0x0833BFE4 (12 bytes),
>script=/usr/local/www/data/Login/users_login.php
>mod_files.c(134) :  Freeing 0x0822DFA4 (33 bytes),
>script=/usr/local/www/data/Login/users_login.php
>mod_files.c(209) :  Freeing 0x081BBC64 (5 bytes),
>script=/usr/local/www/data/Login/users_login.php
>mod_files.c(201) :  Freeing 0x08335E24 (16 bytes),
>script=/usr/local/www/data/Login/users_login.php
>session.c(873) :  Freeing 0x081F60A4 (33 bytes),
>script=/usr/local/www/data/Login/users_login.php
>zend_compile.c(1605) :  Freeing 0x083186E4 (12 bytes),
>script=/usr/local/www/data/Login/users_login.php
>Last leak repeated 3 times
>main.c(1059) :  Freeing 0x081B9C24 (48 bytes),
>script=/usr/local/www/data/home/menu_walled_garden.php
>
>
>
>This goes on for some time, so if you want to see it all, you can find
>the full version at http://www.deadmime.org/~dank/sitics-error.log
>
>But it also leaves an interesting spot in the middle:
>
>---
>zend_opcode.c(168) : Block 0x081ACAC0 status:
>zend_variables.c(62) : Actual location (location was relayed)
>Beginning:  OK (allocated on ./zend_language_scanner.l:739, 89
>bytes)
>   End:  Overflown (magic=0x283F791C instead of 0x2A8FCC84)
> At least 4 bytes overflown
>---
>
><. SOME TIME/BAD-FILE-REQUESTS PASSING  >
>
>--

[PHP-DEV] Re: [PHP-QA] 4.0.5RC1 crash...

[André Langhorst]

Dan Kalowsky wrote:

> Follow up on the earlier reporting of having memory issues to 4.0.5RC1.

most probably not related, me too gets a crash running the standard 
tests on win32, I do not have exactly located the crash, I currently 
short on time

andré

-- 
· André Langhorstt: +49 331 5811560 ·
· [EMAIL PROTECTED]  m: +49 173 9558736 ·
* PHP Quality Assurance  http://qa.php.net  *


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] CVS Account Request

[CVS Account Request]

Full name: hyunsin.kim
Email: [EMAIL PROTECTED]
ID: ssenk
Purpose: company manual update for php

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] CVS Account Request

[CVS Account Request]

Full name: hyunsin.kim
Email: [EMAIL PROTECTED]
ID: ssenk
Purpose: company manual update for php

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9903: Premature end of script

[drgray]

From: [EMAIL PROTECTED]
Operating system: Win98
PHP version:  4.0.4
PHP Bug Type: Scripting Engine problem
Bug description:  Premature end of script

I installed PHP4.0.4 from the PHP4_win32 distribution on a win98 machine with DUN not 
connected to internet. Use Netscape and type: http://12.0.0.1/.  The apache test page 
comes up.  Edited the httpd.conf for PHP and typed: http://12.0.0.1/test.php.

An error about an internal server error was reported on the browser.  The apache 
error.log had an entry stating" Premature end of script headers in c:/program 
files/apache/cgi-bin/php/php.exe"

The php.ini file is the defalault from the PHP404.exe setup.  I did confirm the 
extensions_ line is pointing to my php directory.

I selected the interbase extension only, dm and one other were enabled by default so I 
left them.  I have MySQL installed on the machine but not running.

I would like to use the machine for local (not connected) development when on the road.
 


-- 
Edit Bug report at: http://bugs.php.net/?id=9903&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Andi Gutmans]

At 05:03 PM 3/21/2001 +0100, Sascha Schumann wrote:
> > The bottom line is that, as I said, the trick in good opensource software
> > is taking calculated risks, and mixing agility with quality assurance.  One
> > can look through your binary glasses, and then it's either complete lack of
> > quality, or complete lack of risks, and one can look with reasonable
> > experienced eyes and strive to get to the right mixture.  I, for one, don't
> > enjoy looking through these binary glasses.
>
> Then please start explaining what the right mixture is.
> Apparently, we have not found the right mixture yet, unless
> of course, patchlevel releases are part of that Great Plan.

I think most (probably not all) pl's were sparked due to security bugs 
which were found and we took the opportunity to add another couple of 
important fixes. Those kind of pl's would not have been prevented by any 
Great Plan.

Andi


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9904: error_reporting setting in apache conf not respected in pages

[sklar]

From: [EMAIL PROTECTED]
Operating system: Linux host 2.2.12-20 #1 Mon Sep 27 10:40:35 EDT 1999 i686 unknown
PHP version:  4.0 Latest CVS (20/03/2001)
PHP Bug Type: PHP options/info functions
Bug description:  error_reporting setting in apache conf not respected in pages

The error_reporting setting I put in my apache conf doesn't work in my pages, but if I 
call error_reporting() with the same value in the page, it works. I am using build 
php4-200103160645. I am attempting to follow the instructions at 
http://www.php.net/manual/cs/x49925.php. PHP is configured suchly:
./configure '--with-apache=../apache_1.3.19+mod_ssl'
   '--with-mysql=/usr/local/mysql-3.23.32-pc-linux-gnu-i686' '--with-xml'
   '--enable-track-vars' '--without-ldap' '--without-imap' '--without-gd'

The relevant section of my httpd.conf:

php_value track_vars   1
php_value track_errors 1
php_value display_errors   0
php_value log_errors   1
php_value error_reporting "E_ALL & ~ ( E_NOTICE )"

In a page,  reports back 
E_ALL & ~ ( E_NOTICE )
Calling phpinfo() also reports the same Local Value for error_reporting

However, If I have a page that looks like this:



Nothing appears in the error log.



Also puts nothing in the error log, I guess because it hits the parse error before the 
error_reporting() function call gets executed.

However, a page like this:



puts nothing in the error log, while



correctly puts a message in the error log ("PHP Fatal Error: Call to undefined 
function: imaginary_function() .")

My php.ini only has entries for include_path, max_execution_time, and track_errors, 
nothing about error_reporting.

The same behavior happens if the error_reporting setting in my httpd.conf is just 
E_ALL.




-- 
Edit Bug report at: http://bugs.php.net/?id=9904&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] ImageMagick module for PHP

[Rasmus Lerdorf]

It probably should go in, but it is doing ok as a standalone extension.
It builds easily and the author can maintain his own release schedule.

-Rasmus

On Wed, 21 Mar 2001, Mike Robinson wrote:

>
> Rasmus Lerdorf writes:
>
> > Because it didn't work, and the ImageMagick library is absolutely
> > horrible.  Have a look at the Imlib2 extension.
> >
> > -Rasmus
>
> I surprised imlib2 hasn't made it into the php source.
> It is quite nice.
>
> Perhaps its time it graduated. :)
>
> .mike
>
>
>
> > On Wed, 21 Mar 2001, [iso-8859-1] Ragnar Kjørstad wrote:
> >
> > > Hi
> > >
> > > I see there is a Image Magick module for php3 but not php4.
> > > Why was it removed?
> > >
> > > Is there any work in progress for reimplementing it?
> > > (we need it badly, and will considder joining the development)
>


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] 4.0.5RC1 crash...

[Dan Kalowsky]

Tough question.  We haven't been testing the 4.0.4pl1 as much, but the
behavior doesn't seem to found there.  Mind you this could be due to a
lack of complete testing on our part.  I will see if it's possible to
revert back to 4.0.4pl1 and try some more, but judging by the past
occurances, the earliest I could say is in two days time.

Zeev Suraski wrote:
> 
> Is this a new issue in 4.0.5?  Or did the problem exist in older versions
> as well?
> 
> Zeev

-- 
Dan Kalowsky  "Tonight I think I'll walk alone, 
Worldgate Communications   I'll find my soul as I go home."
Software Engineer - TICS Group  - Temptation

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] free() errors in PHP-4.0.5RC1

[Anil Madhavapeddy]

One of my OpenBSD servers hosed itself overnight, after the upgrade
to PHP-4.0.5RC1.  The problem was that the webserver suddenly
segfaulted all of its children (saw this in the error log), and then dumped
around 900MB worth of errors into the error log.  This hurt my /var
partition :-)

The errors are:

httpd in free(): warning: chunk is already free.
httpd in free(): warning: chunk is already free.
httpd in free(): warning: chunk is already free.
httpd in free(): warning: chunk is already free.
httpd in free(): warning: page is already free.
httpd in free(): warning: chunk is already free.
httpd in free(): warning: chunk is already free.
httpd in free(): warning: chunk is already free.
 ... until /var fills up ...

Now, this is a BSD warning, and I can turn it off by fiddling with
/etc/malloc.conf, but the fact that it's showing up is a bit iffy.
Anyone got any insight?  Nothing like this happened using
PHP-4.0.4pl1 or previous.

More details will be forthcoming if I can reproduce the problem
(it doesn't help that the Apache error logs seem to lack a timestamp).
This is the server that runs demo.horde.org, so it primarily
uses the IMAP module for remote, unstable connections.

Anil



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Sascha Schumann]

> I think most (probably not all) pl's were sparked due to security bugs
> which were found and we took the opportunity to add another couple of
> important fixes. Those kind of pl's would not have been prevented by any
> Great Plan.

If I remember correctly, 4.0.4pl1 was the only release
which also happened to include security-related changes
beside important bug fixes.

Here is a quick summary.

4.0.4pl1, two weeks after 4.0.4
- broken user function calls affects modules like XML and
  Session, broken Apache Config

4.0.3pl1, three days after 4.0.3
- broken Apache Config handling

4.0.1pl2, two days after 4.0.1
- broken error_reporting() and readdir()

4.0b4pl1, one day after 4.0b4
- magic_quotes crash

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] free() errors in PHP-4.0.5RC1

[Dan Kalowsky]

You'll find the same lines inside of the email I sent earlier entitled
"PHP4.0.5RC1 crash..." plus a GDB backtrace I was able to grab at the
moment of occurance (and one from a core file).

I localized it down a bit more to a single script causing it, after
having been under a heavy load for a few days.  You can check the
http://www.deadmime.org/~dank/sitics-error.log (large file) file for the
series of memory leaks that seemed to have caused this.

But if your system hasn't had any of these extra memory leak lines, I
might have to return to my theory of whats causing it... :\  It also
didn't fill up my /var with the free lines...

-- 
Dan Kalowsky  "Tonight I think I'll walk alone, 
Worldgate Communications   I'll find my soul as I go home."
Software Engineer - TICS Group  - Temptation

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9718 Updated: Memory leak when passing String values into methods through COM

[phanto]

ID: 9718
Updated by: phanto
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: COM related
Assigned To: 
Comments:

fixed.

Previous Comments:
---

[2001-03-20 17:59:36] [EMAIL PROTECTED]
I think that you've fixed the problem. Thanks.

---

[2001-03-20 17:44:44] [EMAIL PROTECTED]
could you try again with the latest cvs version. i've rewritten a lot.

harald

---

[2001-03-14 16:58:32] [EMAIL PROTECTED]
On that note, changing code to below also leaks memory.
Variables html_example_test01, etc are declared as public static variables in the COM 
component.
Methods set_html_example_test01() etc set the static variables to the string values 
passed through the argument.

set_html_example_test01("Test string #01.");
$gbl_obj->set_html_example_test02("Test string #02.");
$gbl_obj->set_html_example_test03("Test string #03.");
$gbl_obj->set_html_example_test04("Test string #04.");
$gbl_obj->set_html_example_test05("Test string #05.");
$gbl_obj->set_html_example_test06("Test string #06.");
$gbl_obj->set_html_example_test07("Test string #07.");
$gbl_obj->set_html_example_test08("Test string #08.");
$gbl_obj->set_html_example_test09("Test string #09.");
$gbl_obj->set_html_example_test10("Test string #10.");
$gbl_obj->set_html_example_test11("Test string #11.");
$gbl_obj->set_html_example_test12("Test string #12.");
$gbl_obj->set_html_example_test13("Test string #13.");
$gbl_obj->set_html_example_test14("Test string #14.");
$gbl_obj->set_html_example_test15("Test string #15.");
$gbl_obj->set_html_example_test16("Test string #16.");
$gbl_obj->set_html_example_test17("Test string #17.");
$gbl_obj->set_html_example_test18("Test string #18.");
$gbl_obj->set_html_example_test19("Test string #19.");
$gbl_obj->set_html_example_test20("Test string #20.");

// script does not leak memory when I remove this code block
?>


I hope this clarifies the problem. Earlier examples weren't right as I have done lots 
of code with COM which work without leaking memory.

---

[2001-03-14 16:46:18] [EMAIL PROTECTED]
Disregard my previous example with the classes. I've just tried a test without using 
classes and it still leaks memory. Consider example below instead, thanks:

Code block sets multiple public variables in COM object.
In below example, $gbl_obj is an instance of the COM object in the global scope of the 
PHP page. The public variables are defined as html_example_test01, 
html_example_test02, html_example_test03, etc. etc. My code block sets over twenty 
public variables in the COM object.

html_example_test01 = "Test string #01.";
$gbl_obj->html_example_test02 = "Test string #02.";
$gbl_obj->html_example_test03 = "Test string #03.";
$gbl_obj->html_example_test04 = "Test string #04.";
$gbl_obj->html_example_test05 = "Test string #05.";
$gbl_obj->html_example_test06 = "Test string #06.";
$gbl_obj->html_example_test07 = "Test string #07.";
$gbl_obj->html_example_test08 = "Test string #08.";
$gbl_obj->html_example_test09 = "Test string #09.";
$gbl_obj->html_example_test10 = "Test string #10.";
$gbl_obj->html_example_test11 = "Test string #11.";
$gbl_obj->html_example_test12 = "Test string #12.";
$gbl_obj->html_example_test13 = "Test string #13.";
$gbl_obj->html_example_test14 = "Test string #14.";
$gbl_obj->html_example_test15 = "Test string #15.";
$gbl_obj->html_example_test16 = "Test string #16.";
$gbl_obj->html_example_test17 = "Test string #17.";
$gbl_obj->html_example_test18 = "Test string #18.";
$gbl_obj->html_example_test19 = "Test string #19.";
$gbl_obj->html_example_test20 = "Test string #20.";

// script does not leak memory when I remove this code block
?>

I am using long variable names like html_example_test01






---

[2001-03-14 09:06:35] [EMAIL PROTECTED]
Corrections to bug report. Ignore previous example, check with the below example 
instead.

I'm actually assigning values from inside a child class in PHP and accessing the COM 
object in the base class.

eg:

obj->testvar = "This is a test string.";
  }
}

class Base {
  function instance() {
$this->obj = new COM("MyObject.MyObject");
  }

}

?>

/ Leaks memory when I assign a string to a public variable (testvar) of COM object 
(obj) from an instance of Child.

Disregard my previous examples as I've tested my COM object with a simple string 
passed as argument to method and it did not leak memory.

I think the above memory leak has something to do with PHP's handling of Object 
Oriented Programming...


---

The remainder o

Re: [PHP-DEV] CORBA/PHP

[David Eriksson]

On Wed, 21 Mar 2001, Nick Loman wrote:

>
> Hi
>
> I've got a fairly urgent requirement to get Satellite working properly on
> my PHP 4.0.4pl1 system and can't get in touch with David Eriksson. Has
> anyone had luck with the setup, specifically accessing objects through
> IIOP over TCP/IP who would be prepared to share configs with me? I am
> compiled OK and the mod is installed but it seg faults each time with
> glib errors in the log file whenever I call new Object.
>
> Or if anyone knows where David is likely to be I would very much
> appreciate being put in touch with him.

I'm only busy, and supporting Satellite is unfortunatly not top priority.

I got your mail and it's in my inbox, waiting for investigation...

Sincerely,

-\- David Eriksson -/-

"An expert in a particular computer language is really an expert
in the work-arounds necessary to use this language to perform
useful work." - Richard B. Johnson


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Function design recomendation?

[Fredrik Ohrn]

I'm about to properly implement cpdf_set_viewer_preferences which is
currently just a stub.

The underlying function takes a struct with 8 fields.

I'd like to avoid having to specify 8 parameters to the PHP equivalent
(especially as most of them has sensible defaults).

How are structs 'emulated' in other places?


Regards,
Fredrik

-- 
Do fish get thirsty?

Fredrik Öhrn   Chalmers University of Technology
[EMAIL PROTECTED]  Sweden


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Andi Gutmans]

A couple of these were buffer overflows IIRC which were security issues.
Remember the group@ emails about those?
Andi

At 07:17 PM 3/21/2001 +0100, Sascha Schumann wrote:
> > I think most (probably not all) pl's were sparked due to security bugs
> > which were found and we took the opportunity to add another couple of
> > important fixes. Those kind of pl's would not have been prevented by any
> > Great Plan.
>
> If I remember correctly, 4.0.4pl1 was the only release
> which also happened to include security-related changes
> beside important bug fixes.
>
> Here is a quick summary.
>
> 4.0.4pl1, two weeks after 4.0.4
> - broken user function calls affects modules like XML and
>   Session, broken Apache Config
>
> 4.0.3pl1, three days after 4.0.3
> - broken Apache Config handling
>
> 4.0.1pl2, two days after 4.0.1
> - broken error_reporting() and readdir()
>
> 4.0b4pl1, one day after 4.0b4
> - magic_quotes crash
>
> - Sascha Experience IRCG
>   http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Function design recomendation?

[Sterling Hughes]

On Wed, 21 Mar 2001, Fredrik Ohrn wrote:

> 
> I'm about to properly implement cpdf_set_viewer_preferences which is
> currently just a stub.
> 
> The underlying function takes a struct with 8 fields.
> 
> I'd like to avoid having to specify 8 parameters to the PHP equivalent
> (especially as most of them has sensible defaults).
> 
> How are structs 'emulated' in other places?
> 
>

You have a couple of options...

First of all are you sure that the user needs to specify all 8 fields of
the structure, or can you safely fill in some of them?

As a second option you could have the user pass an associative array which
is the closed equivalent of a structure in php.

-Sterling


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] free() errors in PHP-4.0.5RC1

[Anil Madhavapeddy]

> I localized it down a bit more to a single script causing it, after
> having been under a heavy load for a few days.  You can check the
> http://www.deadmime.org/~dank/sitics-error.log (large file) file for the
> series of memory leaks that seemed to have caused this.
> 
> But if your system hasn't had any of these extra memory leak lines, I
> might have to return to my theory of whats causing it... :\  It also
> didn't fill up my /var with the free lines...

Hmm yeah these are different errors - in this case, you aren't
free()ing enough memory, but my errors are that the memory is
being free()ed too often!  

Perhaps in fixing a leak, someone didn't put in a check to see
if it was already free.

This is going to be tough to track down unless I can reproduce it :-/

Anil


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Sascha Schumann]

On Wed, 21 Mar 2001, Andi Gutmans wrote:

> A couple of these were buffer overflows IIRC which were security issues.
> Remember the group@ emails about those?

Fixes against format-string attacks and for file-upload
issues went into 4.0.3.  Or what are you referring to?

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Andi Gutmans]

Why do we need to have an interrogation. Relax, it's not such a big deal.

4.0.4pl1 & 4.0.3pl1 both had security fixes (Apache config handling was a 
security issue).

Anyway, I still don't understand what the big fuss is about. Let's stop 
arguing about this like 4th graders.
By the way, the error_reporting() pl1 in 4.0.1 was due to a bug which was 
in the CVS a long time. It was not a spontaneous bug that was introduced.

Andi

At 07:50 PM 3/21/2001 +0100, Sascha Schumann wrote:
>On Wed, 21 Mar 2001, Andi Gutmans wrote:
>
> > A couple of these were buffer overflows IIRC which were security issues.
> > Remember the group@ emails about those?
>
> Fixes against format-string attacks and for file-upload
> issues went into 4.0.3.  Or what are you referring to?
>
> - Sascha Experience IRCG
>   http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Zeev Suraski]

At 20:50 21/3/2001, Sascha Schumann wrote:
>On Wed, 21 Mar 2001, Andi Gutmans wrote:
>
> > A couple of these were buffer overflows IIRC which were security issues.
> > Remember the group@ emails about those?
>
> Fixes against format-string attacks and for file-upload
> issues went into 4.0.3.  Or what are you referring to?

The Apache module issue was a security problem.  A fairly major one, too.

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Cynic]

Hi Andi!

At 19:58 21.3. 2001, Andi Gutmans wrote the following:
-- 
>Why do we need to have an interrogation. Relax, it's not such a big deal.

We don't. I hope no one will take my remarks personally. :)

>4.0.4pl1 & 4.0.3pl1 both had security fixes (Apache config handling was a security 
>issue).

One might consider all bugs security issues.

>By the way, the error_reporting() pl1 in 4.0.1 was due to a bug which was in the CVS 
>a long time. It was not a spontaneous bug that was introduced.

Well, how come it wasn't serious enough to make it into 4.0.1,
and two days later it justified a release of pl1? :) I guess 
such a situation was a symptom of a need for a better RC process...
It improved. I understand Sascha's fear the group was backpedalling 
from the position it has achieved. 

I must say I agree with Sascha and the other people who wrote that 
they'd prefer new stuff _not_ added during an RC period. 
Apache group has a pretty different modus operandi more like FreeBSD
with a group of commiters, and if you check [EMAIL PROTECTED], 
you'll see that they're trying to tighten it even more. They tossed 
CVS branches, and it seems like they're going to use code-freeze 
periods. Now, before someone jumps on this, I know PHP isn't Apache,
and there are other projects that do well without freezes, but I 
still think PHP is a bit too liberal in this area.


>At 07:50 PM 3/21/2001 +0100, Sascha Schumann wrote:
>>On Wed, 21 Mar 2001, Andi Gutmans wrote:
>>
>>> A couple of these were buffer overflows IIRC which were security issues.
>>> Remember the group@ emails about those?
>>
>>Fixes against format-string attacks and for file-upload
>>issues went into 4.0.3.  Or what are you referring to?
>>
>>- Sascha Experience IRCG
>>  http://schumann.cx/http://schumann.cx/ircg
--end of quote-- 


[EMAIL PROTECTED]
-
And the eyes of them both were opened and they saw that their files
were world readable and writable, so they chmoded 600 their files.
- Book of Installation chapt 3 sec 7 


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Sascha Schumann]

> The Apache module issue was a security problem.  A fairly major one, too.

Yes, that is why I mentioned 4.0.4pl1 as an exception in an
earlier email.

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Sascha Schumann]

On Wed, 21 Mar 2001, Andi Gutmans wrote:

> Why do we need to have an interrogation. Relax, it's not such a big deal.

I'm completely relaxed.  I just dislike twisting history.

- Sascha Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Function design recomendation?

[Andrei Zmievski]

On Wed, 21 Mar 2001, Fredrik Ohrn wrote:
> 
> I'm about to properly implement cpdf_set_viewer_preferences which is
> currently just a stub.
> 
> The underlying function takes a struct with 8 fields.
> 
> I'd like to avoid having to specify 8 parameters to the PHP equivalent
> (especially as most of them has sensible defaults).
> 
> How are structs 'emulated' in other places?

Associative array keyed by preference name?

-Andrei
* I wish life had an UNDO function. *

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] 4.0.5RC1 crash...

[Jani Taskinen]

On Wed, 21 Mar 2001, Dan Kalowsky wrote:

>[Fri Mar 16 09:42:37 2001] [notice] SIGHUP received.  Attempting to

Ehem. Did you try to 'apachectl stop ; apachectl start' ??
I've seen odd things to happen if 'apachectl restart' is used.

--Jani


>restart
>[Fri Mar 16 09:42:38 2001] [notice] Apache/1.3.17 (Unix) mod_perl/1.24
>PHP/4.0.5RC1 configured -- resuming normal operations
>zend_hash.c(202) :  Freeing 0x083066E4 (20 bytes),
>script=/usr/local/www/data/Login/users_login.php
>zend_API.c(219) :  Freeing 0x08173124 (48 bytes),
>script=/usr/local/www/data/Login/users_login.php
>zend_API.c(208) : Actual location (location was relayed)
>zend_hash.c(202) :  Freeing 0x0835E6E4 (20 bytes),
>script=/usr/local/www/data/Login/users_login.php
>zend_API.c(219) :  Freeing 0x081E37A4 (48 bytes),
>script=/usr/local/www/data/Login/users_login.php
>zend_API.c(208) : Actual location (location was relayed)
>[Fri Mar 16 17:13:05 2001] [error] [client 172.16.64.5] File does not
>exist: /usr/local/www/data/interactive/internet/index.html
>
>
>Yet again even more.  from Friday March 19th
>zend_hash.c(202) :  Freeing 0x081B9E24 (20 bytes),
>script=/usr/local/www/data/Login/users_login.php
>zend_API.c(219) :  Freeing 0x081B86A4 (48 bytes),
>script=/usr/local/www/data/Login/users_login.php
>zend_API.c(208) : Actual location (location was relayed)
>zend_hash.c(202) :  Freeing 0x081A8E24 (20 bytes),
>script=/usr/local/www/data/Login/users_login.php
>zend_API.c(219) :  Freeing 0x0819F5A4 (48 bytes),
>script=/usr/local/www/data/Login/users_login.php
>zend_API.c(208) : Actual location (location was relayed)
>zend_hash.c(202) :  Freeing 0x081BAE24 (20 bytes),
>script=/usr/local/www/data/Login/users_login.php
>zend_API.c(219) :  Freeing 0x081A96A4 (48 bytes),
>script=/usr/local/www/data/Login/users_login.php
>zend_API.c(208) : Actual location (location was relayed)
>zend_hash.c(202) :  Freeing 0x081B8E24 (20 bytes),
>script=/usr/local/www/data/Login/users_login.php
>Last leak repeated 212 times
>zend_opcode.c(304) :  Freeing 0x08205024 (2100 bytes),
>script=/usr/local/www/data/Login/users_login.php
>Last leak repeated 1 time
>./zend_language_scanner.l(1059) :  Freeing 0x0820D824 (39 bytes),
>script=/usr/local/www/data/Login/users_login.php
>Last leak repeated 8 times
>zend_hash.c(461) :  Freeing 0x081DCBA4 (76 bytes),
>script=/usr/local/www/data/Login/users_login.php
>Last leak repeated 13 times
>./zend_execute.c(1629) :  Freeing 0x0824B564 (24 bytes),
>script=/usr/local/www/data/Login/users_login.php
>zend_variables.c(117) : Actual location (location was relayed)
>Last leak repeated 41 times
>Last leak repeated 6 times
>var.c(475) :  Freeing 0x0833AA24 (2 bytes),
>script=/usr/local/www/data/Login/users_login.php
>Last leak repeated 15 times
>var.c(562) :  Freeing 0x0833A9A4 (12 bytes),
>script=/usr/local/www/data/Login/users_login.php
>Last leak repeated 16 times
>session.c(501) :  Freeing 0x082529A4 (48 bytes),
>script=/usr/local/www/data/Login/users_login.php
>zend_API.c(188) : Actual location (location was relayed)
>session.c(500) :  Freeing 0x0833BFE4 (12 bytes),
>script=/usr/local/www/data/Login/users_login.php
>mod_files.c(134) :  Freeing 0x0822DFA4 (33 bytes),
>script=/usr/local/www/data/Login/users_login.php
>mod_files.c(209) :  Freeing 0x081BBC64 (5 bytes),
>script=/usr/local/www/data/Login/users_login.php
>mod_files.c(201) :  Freeing 0x08335E24 (16 bytes),
>script=/usr/local/www/data/Login/users_login.php
>session.c(873) :  Freeing 0x081F60A4 (33 bytes),
>script=/usr/local/www/data/Login/users_login.php
>zend_compile.c(1605) :  Freeing 0x083186E4 (12 bytes),
>script=/usr/local/www/data/Login/users_login.php
>Last leak repeated 3 times
>main.c(1059) :  Freeing 0x081B9C24 (48 bytes),
>script=/usr/local/www/data/home/menu_walled_garden.php
>
>
>
>This goes on for some time, so if you want to see it all, you can find
>the full version at http://www.deadmime.org/~dank/sitics-error.log
>
>But it also leaves an interesting spot in the middle:
>
>---
>zend_opcode.c(168) : Block 0x081ACAC0 status:
>zend_variables.c(62) : Actual location (location was relayed)
>Beginning:  OK (allocated on ./zend_language_scanner.l:739, 89
>bytes)
>  End:  Overflown (magic=0x283F791C instead of 0x2A8FCC84)
>At least 4 bytes overflown
>---
>
><. SOME TIME/BAD-FILE-REQUESTS PASSING  >
>
>---
>zend_opcode.c(168) : Block 0x08AE4B80 status:
>zend_variables.c(62) : Actual location (location was relayed)
>Beginning:  OK (allocated on ./zend_language_scanner.l:1152, 217
>bytes)
>  End:  Overflown (magic=0x283F791C instead of 0x2A8FCC84)
>At least 4 bytes overflown
>---
>[Tue Mar 20 23:50:21 2001] [notice] child pid 257 exit signal
>Segmentation fault (11), possible coredump in /usr/local
>[Tue Mar 20 23:58:11 2001] [error] [client 172.16.64.5] File does not
>exist

Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Zeev Suraski]

But I referred to 4.0.3pl1 :)

At 21:23 21/3/2001, Sascha Schumann wrote:
> > The Apache module issue was a security problem.  A fairly major one, too.
>
> Yes, that is why I mentioned 4.0.4pl1 as an exception in an
> earlier email.
>
> - Sascha Experience IRCG
>   http://schumann.cx/http://schumann.cx/ircg

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9880 Updated: Apache Core dumps when trying to execute. No compilation errors.

[sniper]

ID: 9880
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: Apache related
Assigned To: 
Comments:

Could you please try the latest CVS snapshot from http://snaps.php.net/ and add 
--enable-debug to your configure line to get useful backtrace.

--Jani


Previous Comments:
---

[2001-03-20 14:44:37] [EMAIL PROTECTED]
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.7"...(no debugging symbols found)...
Core was generated by `/usr/local/apache/bin/httpd'.
Program terminated with signal 11, Segmentation Fault.
Reading symbols from /usr/lib/libpam.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libpam.so.1
Reading symbols from /usr/lib/libdl.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libdl.so.1
Reading symbols from /usr/lib/libsched.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libsched.so.1
Reading symbols from /usr/lib/libgen.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libgen.so.1
Reading symbols from /usr/lib/libsocket.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libsocket.so.1
Reading symbols from /usr/lib/libnsl.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libnsl.so.1
Reading symbols from /usr/lib/libresolv.so.2...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libresolv.so.2
Reading symbols from /usr/lib/libm.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libm.so.1
Reading symbols from /usr/lib/libcrypt_i.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libcrypt_i.so.1
Reading symbols from /app/oracle/product/8.1.6/lib/libclntsh.so.8.0...(no debugging 
symbols found)...done.
Loaded symbols for /app/oracle/product/8.1.6/lib/libclntsh.so.8.0
Reading symbols from /usr/lib/libc.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libc.so.1
Reading symbols from /usr/lib/libmp.so.2...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libmp.so.2
Reading symbols from /app/oracle/product/8.1.6/lib/libwtc8.so...(no debugging symbols 
found)...done.
Loaded symbols for /app/oracle/product/8.1.6/lib/libwtc8.so
Reading symbols from /usr/lib/libaio.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libaio.so.1
Reading symbols from /usr/platform/SUNW,Ultra-Enterprise-1/lib/libc_psr.so.1...(no 
debugging symbols found)...done.
Loaded symbols for /usr/platform/SUNW,Ultra-Enterprise-1/lib/libc_psr.so.1
Reading symbols from /usr/lib/nss_files.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/nss_files.so.1
#0  0xff0b6dec in strlen () from /usr/lib/libc.so.1

(gdb) run -X
Starting program: /usr/local/apache/bin/httpd -X
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols 
found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols 
found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols 
found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols 
found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0xff0b6dec in strlen () from /usr/lib/libc.so.1
(gdb) bt
#0  0xff0b6dec in strlen () from /usr/lib/libc.so.1
#1  0xb3be0 in zend_register_functions ()
#2  0xb402c in zend_register_internal_class ()
#3  0x44260 in php_minit_oci ()
#4  0xb3b18 in zend_startup_module ()
#5  0x2dbc4 in php_startup_extensions ()
#6  0x2ec64 in php_startup_internal_extensions ()
#7  0x2ded0 in php_module_startup ()
#8  0x2af8c in sapi_apache_send_headers ()
#9  0x2bfc0 in php_init_handler ()
#10 0x11bd10 in ap_init_modules ()
#11 0x12a5e4 in main ()


This is the output.  When trying to execute "apachectl start" it immediately core 
dumps.

Jason

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9880&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: [PHP-QA] 4.0.5RC1 crash...

[Dan Kalowsky]

Jani Taskinen wrote:
> 
> On Wed, 21 Mar 2001, Dan Kalowsky wrote:
> 
> >[Fri Mar 16 09:42:37 2001] [notice] SIGHUP received.  Attempting to
> 
> Ehem. Did you try to 'apachectl stop ; apachectl start' ??
> I've seen odd things to happen if 'apachectl restart' is used.

Yep.  'apachectl stop' and 'apachectl start' are the prefered methods
here for some of the very same reason you've seen (probably).



-- 
Dan Kalowsky  "Tonight I think I'll walk alone, 
Worldgate Communications   I'll find my soul as I go home."
Software Engineer - TICS Group  - Temptation

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Zeev Suraski]

At 21:25 21/3/2001, Sascha Schumann wrote:
>On Wed, 21 Mar 2001, Andi Gutmans wrote:
>
> > Why do we need to have an interrogation. Relax, it's not such a big deal.
>
> I'm completely relaxed.  I just dislike twisting history.

Sascha,

As Cynic said, it's really a good idea to stop the flame wars.  Being 
cynical (nice coincidence) doesn't help, because it draws cynical remarks 
from the other side (as you could see).  Let's just stop.  The argument 
diverted to unrelated issues anyway.

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9636 Updated: error message

[sniper]

ID: 9636
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Compile Failure
Assigned To: 
Comments:

Get the latest CVS snapshot (from today) add --enable-debug into your configure line 
and configure, 'make clean ; make ; make install'

And then generate a GDB backtrace of the crash.
(as it most likely is crashing)
And if it happens with specific script, add the (shortest)
possible script into this bug report that can be used
to reproduce the crash.

--Jani




Previous Comments:
---

[2001-03-08 19:09:37] [EMAIL PROTECTED]
Please try the latest CVS snapshot from http://snaps.php.net/

--Jani


---

[2001-03-08 15:03:06] [EMAIL PROTECTED]
For Netscape Enterprise Server configuration:

After installing all the necessary packages and running
"./configure --with-mysql=/usr/local/mysql --with-nsapi=
/opt/netscape/suitespot --enable-track-vars --enable-libgcc"

When attempting to run "make" I get the following:

# make
Making all in Zend
Making all in Zend
/bin/sh ../libtool --silent --mode=compile c++ -DHAVE_CONFIG_H -I. -I. -I../main
   -D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -DXML_BYTE
_ORDER=21 -I../TSRM  -g -O2 -pthreads -c zend_language_scanner_cc.cc
In file included from zend_language_scanner_cc.cc:2571:
zend_operators.h: In function `int is_numeric_string(char *, int, long int *, do
uble *)':
zend_operators.h:84: implicit declaration of function `int finite(...)'
make[1]: *** [zend_language_scanner_cc.lo] Error 1
make[1]: Leaving directory `/usr/local/php-4.0.4pl1/Zend'
make: *** [all-recursive] Error 1
#

Running gcc-2.95_2

Thanks,
Bob Smith
Computer Systems Administrator
East Carolina University
[EMAIL PROTECTED]
(252) 328-0421

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9636&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9887 Updated: Files appear to be missing

[sniper]

ID: 9887
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: *Install and Config
Assigned To: 
Comments:

User error.

--Jani


Previous Comments:
---

[2001-03-21 01:08:11] [EMAIL PROTECTED]
In the "INSTALL" file included with the installation of PHP, it instructs me to 
reference 2 files in the httpd.conf: mod_php4.c and libphp4.so.  Neither of these 
files exist in the installation package, nor are they created during the installation. 
 I never see any errors during my installation; everything appears to go just fine.  
I've installed older versions of PHP4 without a problem, so I am fairly sure it's 
nothing to do with my computer.  Any help you can offer would be greatly appreciated.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9887&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9891 Updated: Finnish mirror is *ucked up

[sniper]

ID: 9891
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: Unknown/Other Function
Assigned To: 
Comments:

Inform [EMAIL PROTECTED] about it. (not a bug in PHP the language!)

--Jani


Previous Comments:
---

[2001-03-21 03:50:51] [EMAIL PROTECTED]
Parse error: parse error in /usr/htdocs/mirrors/phpweb/index.php on line 2

This problem occures when entering http://fi.php.net/

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9891&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] CVS Account Request

[CVS Account Request]

Full name: Tomas V.V.Cox
Email: [EMAIL PROTECTED]
ID: cox
Purpose: Pear DB Informix Extension

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9890 Updated: Output line too long.

[sniper]

ID: 9890
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: Compile Problem
Assigned To: 
Comments:

So, is it 4.0.2 or 4.0.4pl1 you're trying?
Anyway, try the latest CVS snapshot from http://snaps.php.net/ and if that doesn't 
work either,
check the version of 'lex' your've got in your system.

You could also try to use the GNU flex from 
ftp://ftp.gnu.org/non-gnu/flex/flex-2.5.4a.tar.gz

--Jani


Previous Comments:
---

[2001-03-21 02:06:00] [EMAIL PROTECTED]
I want to install php_4.0.2 on my Soalris 2.6 sparc system, when do configure, it give 
me the error message: 
... 
... 
Checking lex output file root.. 
output line too long. 
output line too long. 
output line too long. 
output line too long. 
output line too long. 
.. 
.. 
It repeated to display the error message, and not stop. 
It also happen on php version 4, but when I install Php version 3, it is no problem.
What is the problem? how can resolve it? 


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9890&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9894 Updated: Fatal error: Call to undefined function: ora_logon() in e:\web\root\index.php o

[sniper]

ID: 9894
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Old-Bug Type: MySQL related
Bug Type: Oracle related
Assigned To: 
Comments:

You haven't uncommented the line in php.ini to load php_oci8.dll:

;extension=php_oci8.dll

Remove the ; in front of the line.

You should also read this page:

http://www.php.net/oci8

--Jani


Previous Comments:
---

[2001-03-21 06:07:23] [EMAIL PROTECTED]


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9894&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9905: Error on www.php.net

[mkknapp]

From: [EMAIL PROTECTED]
Operating system: NA
PHP version:  4.0.4pl1
PHP Bug Type: Documentation problem
Bug description:  Error on www.php.net

This is a minor issue, but the date at the top right of www.php.net is inconsistant.  
On alternating sections, it is one day behind. Thus on documentation, support, and 
links, it says it is yesterday, but on downloads, faq, and reporting bugs, it is the 
right day.

I don't know if this is the right place for this, but I could find another email 
address to report it.

Mark


-- 
Edit Bug report at: http://bugs.php.net/?id=9905&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Jason Greene]

Though I am still considered new to this group, I thought I would put in my two cents.

Are we considering fastcgi module stable?  We currently release EXPERIMENTAL modules
as part of the distribution. If fastcgi is considered EXPERIMENTAL, then I don't see 
why the 
module itself could not be included in the RC branch. The only piece that really has 
to be checked 
is config.m4, and in this scenario there doesn't appear to be problems(efficient or 
not). As long as
the withval test is valid, and the module is not enabled by default it really 
shouldn't affect php
as a whole. I believe that this is a fine exception to the rule.

However, if fastcgi is being labled stable, then, IMHO, I believe it should wait for 
thorough testing,
and the next freeze.  

I think that Sascha, and Jani have concerns with this being the first domino in a 
series of continually
growing exceptions to the release process. An RP ruleset is one of those things that 
is often considered
 "Holy",and shouldn't have reoccuring exceptions. Zeev has expressed valid points 
about the functionality
 being important and shouldn't wait.  Which, if there is big need for it, why can't 
there be a compromise?

Perhaps everyone should consider altering the RP ruleset, to include an exception 
about adding new 
modules. 

If the exception policy was in place here are some questions of thought:
What would be necessary to make it safe to php in a whole?
What should the requirements be to allow this to happen ( ex. a lot of user demand, 
replaces something considered unstable) ?
Should this require any re-testing?
Should this require x amount of RCs to follow and how many?
Should there be a vote on whether or not to allow the module in?
Is this module something that should first be released as an add-on?

I honestly agree with both positions on this one, and I think  good can come from both 
of them : )

-Jason




- Original Message - 
From: "Zeev Suraski" <[EMAIL PROTECTED]>
To: "Sascha Schumann" <[EMAIL PROTECTED]>
Cc: "PHP Developers Mailing List" <[EMAIL PROTECTED]>; "PHP Quality Assurance Team 
Mailing List" <[EMAIL PROTECTED]>
Sent: Wednesday, March 21, 2001 1:33 PM
Subject: Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) 
/sapi/fastcgi


> But I referred to 4.0.3pl1 :)
> 
> At 21:23 21/3/2001, Sascha Schumann wrote:
> > > The Apache module issue was a security problem.  A fairly major one, too.
> >
> > Yes, that is why I mentioned 4.0.4pl1 as an exception in an
> > earlier email.
> >
> > - Sascha Experience IRCG
> >   http://schumann.cx/http://schumann.cx/ircg
> 
> --
> Zeev Suraski <[EMAIL PROTECTED]>
> CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
> 


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9905 Updated: Error on www.php.net

[hholzgra]

ID: 9905
Updated by: hholzgra
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Documentation problem
Assigned To: 
Comments:

can't reproduce, 
probably some caching effect 


Previous Comments:
---

[2001-03-21 15:07:16] [EMAIL PROTECTED]
This is a minor issue, but the date at the top right of www.php.net is inconsistant.  
On alternating sections, it is one day behind. Thus on documentation, support, and 
links, it says it is yesterday, but on downloads, faq, and reporting bugs, it is the 
right day.

I don't know if this is the right place for this, but I could find another email 
address to report it.

Mark

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9905&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Zeev Suraski]

It's definitely considered experimental.

Zeev

At 22:19 21/3/2001, Jason Greene wrote:
>Though I am still considered new to this group, I thought I would put in 
>my two cents.
>
>Are we considering fastcgi module stable?  We currently release 
>EXPERIMENTAL modules
>as part of the distribution. If fastcgi is considered EXPERIMENTAL, then I 
>don't see why the
>module itself could not be included in the RC branch. The only piece that 
>really has to be checked
>is config.m4, and in this scenario there doesn't appear to be 
>problems(efficient or not). As long as
>the withval test is valid, and the module is not enabled by default it 
>really shouldn't affect php
>as a whole. I believe that this is a fine exception to the rule.
>
>However, if fastcgi is being labled stable, then, IMHO, I believe it 
>should wait for thorough testing,
>and the next freeze.
>
>I think that Sascha, and Jani have concerns with this being the first 
>domino in a series of continually
>growing exceptions to the release process. An RP ruleset is one of those 
>things that is often considered
>  "Holy",and shouldn't have reoccuring exceptions. Zeev has expressed 
> valid points about the functionality
>  being important and shouldn't wait.  Which, if there is big need for it, 
> why can't there be a compromise?
>
>Perhaps everyone should consider altering the RP ruleset, to include an 
>exception about adding new
>modules.
>
>If the exception policy was in place here are some questions of thought:
>What would be necessary to make it safe to php in a whole?
>What should the requirements be to allow this to happen ( ex. a lot of 
>user demand, replaces something considered unstable) ?
>Should this require any re-testing?
>Should this require x amount of RCs to follow and how many?
>Should there be a vote on whether or not to allow the module in?
>Is this module something that should first be released as an add-on?
>
>I honestly agree with both positions on this one, and I think  good can 
>come from both of them : )
>
>-Jason
>
>
>
>
>- Original Message -
>From: "Zeev Suraski" <[EMAIL PROTECTED]>
>To: "Sascha Schumann" <[EMAIL PROTECTED]>
>Cc: "PHP Developers Mailing List" <[EMAIL PROTECTED]>; "PHP Quality 
>Assurance Team Mailing List" <[EMAIL PROTECTED]>
>Sent: Wednesday, March 21, 2001 1:33 PM
>Subject: Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: 
>php4(PHP_4_0_5) /sapi/fastcgi
>
>
> > But I referred to 4.0.3pl1 :)
> >
> > At 21:23 21/3/2001, Sascha Schumann wrote:
> > > > The Apache module issue was a security problem.  A fairly major 
> one, too.
> > >
> > > Yes, that is why I mentioned 4.0.4pl1 as an exception in an
> > > earlier email.
> > >
> > > - Sascha Experience IRCG
> > >   http://schumann.cx/http://schumann.cx/ircg
> >
> > --
> > Zeev Suraski <[EMAIL PROTECTED]>
> > CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/
> >
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > To contact the list administrators, e-mail: [EMAIL PROTECTED]
> >

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9896 Updated: segfaults at $xmldoc->add_root("root");

[sniper]

ID: 9896
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: DOM XML related
Assigned To: 
Comments:

Delete config.cache, add --enable-debug into your configure line, 'make clean ; make ; 
make install' and generate a GDB backtrace of the crash and add it into this bug 
report.

--Jani


Previous Comments:
---

[2001-03-21 06:08:29] [EMAIL PROTECTED]
Reproduce with:

$xmldoc = domxml_new_xmldoc('1.0');
domxml_add_root($xmldoc,"bla");

Configure

./configure --with-config-file-path=/usr/local/apache/conf  --with-zlib  --with-mysql  
--with-sablot --with-apxs=/usr/local/apache/bin/apxs --enable-versioning 
--with-dom=/opt/gnome

libxml2-2.3.3




---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9896&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] is_reference() ?

[Björn Schotte]

Hi,

I recently had a discussion with Alexander Aulbach
(submitter of bug reports with unset() and the
inconsistencies with unset($foo) and unset($bar["bla"])
(the latter works, the former not)) and we agreed
that there definitively would be need of a funtion
called

  is_reference(varname)

Sometimes we would like to know if $foo is a references
variable or not (e.g. to ship around the unset() bug
issue).

What do you think?

-- 
Björn Schotte  [EMAIL PROTECTED]
http://rent-a-phpwizard.de/   [EMAIL PROTECTED]

  PHP Schulungen, Softwareentwicklung, Coaching  

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

[Zeev Suraski]

At 22:19 21/3/2001, Jason Greene wrote:
>If the exception policy was in place here are some questions of thought:
>What would be necessary to make it safe to php in a whole?

I'd say that a module that has no effect on building PHP is fine to add as 
an experimental module.  The only reason I believe we need at least one RC 
afterwards, is to ensure that trivial problems weren't introduced (mostly, 
a broken build).

>What should the requirements be to allow this to happen ( ex. a lot of 
>user demand, replaces something considered unstable) ?

I think that these are the same requirements for any other module that we 
decide to admit to the tree.  Since it's not a big deal, if it belongs in 
the PHP 4.0 tree, then it's ok to add it whilst in RC's.

>Should this require any re-testing?
>Should this require x amount of RCs to follow and how many?

IMHO, one more RC.

>Should there be a vote on whether or not to allow the module in?

We don't have a body with 'jurisdiction' other than the PHP Group, so I'd 
say no;  Whatever loose guidelines we use today to admit new modules can 
apply here as well.

>Is this module something that should first be released as an add-on?
>
>I honestly agree with both positions on this one, and I think  good can 
>come from both of them : )

I think that by saying you agree with both positions you attribute to me 
things that I didn't say :)  I'm all in favour of a stable release 
process.  I'm not in favour in considering the release process guidelines 
as 'holy', and if I or anybody else thinks they can be improved, the right 
step would be to raise it for discussion.  As I said to Hartmut, the minute 
bureaucracy becomes sacred, you know you're doing something wrong.  I 
considered the fact that the release process did not account for new 
experimental modules a limitation of the release process.  Even the US 
constitution required a few amendments before they got it right :)

Zeev


--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9898 Updated: gd and mck fail to link but did in 4.0.4pl1

[sniper]

ID: 9898
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: Compile Problem
Assigned To: 
Comments:

I guess you know enough to do './cvsclean ; ./buildconf' after updating CVS ?

And what was the configure line used?

--Jani


Previous Comments:
---

[2001-03-21 07:42:43] [EMAIL PROTECTED]
Weird - can't find my duplicate report, so reopened this one.

I'm having problems with the bug system - it's slow to react and seems to hang.

Anyway, I left this information out:

/bin/sh /home/wez/source/phpbuild/libtool --silent --mode=link gcc  -I. 
-I/home/wez/source/phpbuild/ -I/home/wez/source/phpbuild/main 
-I/home/wez/source/phpbuild -I/usr/include/apache -I/home/wez/source/phpbuild/Zend 
-I/usr/local/include -I/usr/local/mck-3.2.0.3-linux//c-api -I/usr/include/freetype 
-I/usr/include/gd -I/usr/include/imap -I/usr/include/mysql -I/usr/local/include/pspell 
-I/home/CLIENTWEB/sophosantivirus/sav_if 
-I/home/wez/source/phpbuild/ext/xml/expat/xmltok 
-I/home/wez/source/phpbuild/ext/xml/expat/xmlparse -I/home/wez/source/phpbuild/TSRM  
-DEAPI_MM -DLINUX=2 -DMOD_SSL=206105 -DUSE_HSREGEX -DEAPI -DUSE_EXPAT -DSUPPORT_UTF8 
-DXML_BYTE_ORDER=12 -g -O2   -o libphp4.la -rpath /home/wez/source/phpbuild/libs 
-avoid-version -L/usr/local/lib -L/usr/local/mck-3.2.0.3-linux//c-api/lib 
-L/usr/lib/mysql  -R /usr/local/lib -R /usr/local/mck-3.2.0.3-linux//c-api/lib -R 
/usr/lib/mysql stub.lo  Zend/libZend.la sapi/apache/libsapi.la main/libmain.la 
regex/libregex.la ext/bz2/libbz2.la ext/calendar/libcalendar.la ext/curl/libcurl.la 
ext/cybercash/libcybercash.la ext/dbg/libdbg.la ext/ftp/libftp.la ext/gd/libgd.la 
ext/gettext/libgettext.la ext/iconv/libiconv.la ext/imap/libimap.la 
ext/jstring/libjstring.la ext/ldap/libldap.la ext/mailparse/libmailparse.la 
ext/mbregex/libmbregex.la ext/mhash/libmhash.la ext/mysql/libmysql.la 
ext/pcre/libpcre.la ext/posix/libposix.la ext/pspell/libpspell.la ext/savi/libsavi.la 
ext/session/libsession.la ext/shmop/libshmop.la ext/sockets/libsockets.la 
ext/standard/libstandard.la ext/sysvsem/libsysvsem.la ext/sysvshm/libsysvshm.la 
ext/wddx/libwddx.la ext/xml/libxml.la ext/yp/libyp.la ext/zlib/libzlib.la 
TSRM/libtsrm.la -lpam -lsavi -lc-client -ldl -lz -lpspell -lmysqlclient -lmhash -lldap 
-llber -lttf -lz -lpng -lgd -lmckcrypto -lcurl -lbz2 -lresolv -lm -ldl -lcrypt -lnsl 
-lresolv


---

[2001-03-21 07:38:21] [EMAIL PROTECTED]
Sorry - forgot some info which is in the other report.
I'm having B/W problems so the bug system is reacting slowly for me...

---

[2001-03-21 07:28:17] [EMAIL PROTECTED]
the final stage of the build says:
*** Warning: This library needs some functionality provided by -lgd.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.

*** Warning: This library needs some functionality provided by -lmckcrypto.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.

It is correct - I do not have shared versions of these libraries, but previous 
versions of PHP linked correctly.
PHP 4.0.4pl1 still compiles and links, and I'm pretty sure CVS worked about a week 
ago.

--Wez.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9898&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] is_reference() ?

[Andrei Zmievski]

On Wed, 21 Mar 2001, Björn Schotte wrote:
> I recently had a discussion with Alexander Aulbach
> (submitter of bug reports with unset() and the
> inconsistencies with unset($foo) and unset($bar["bla"])
> (the latter works, the former not)) and we agreed
> that there definitively would be need of a funtion
> called
> 
>   is_reference(varname)
> 
> Sometimes we would like to know if $foo is a references
> variable or not (e.g. to ship around the unset() bug
> issue).
> 
> What do you think?

It's not really possible right now due to the way Zend engine works.

-Andrei
* Non-volatile, random-access, analog memory store... a book. *

--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] is_reference() ?

[Zeev Suraski]

At 22:30 21/3/2001, Björn Schotte wrote:
>Hi,
>
>I recently had a discussion with Alexander Aulbach
>(submitter of bug reports with unset() and the
>inconsistencies with unset($foo) and unset($bar["bla"])
>(the latter works, the former not))

Huh?  Both work...?


>  and we agreed
>that there definitively would be need of a funtion
>called
>
>   is_reference(varname)
>
>Sometimes we would like to know if $foo is a references
>variable or not (e.g. to ship around the unset() bug
>issue).
>
>What do you think?

This has been discussed before (as far as I recall).  The engine may 
convert certain variables to be references on the fly, without the user 
requesting it.  So, is_reference() won't mean much to end users.

Zeev


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] is_reference() ?

[Björn Schotte]

Hi,

> It's not really possible right now due to the way Zend engine works.

So it would be better to reopen the bug reports
which considered the unset() issue?

Anyway, is it possible that there may exist
a function like is_reference() in future?

TIA,
-- 
Björn Schotte  [EMAIL PROTECTED]
http://rent-a-phpwizard.de/   [EMAIL PROTECTED]

  PHP Schulungen, Softwareentwicklung, Coaching  

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] is_reference() ?

[Sebastian Bergmann]

Zeev Suraski wrote:
> So, is_reference() won't mean much to end users.

  But it might come in handy in some (debugging) situations, I could
imagine.

-- 
 sebastian bergmann[EMAIL PROTECTED]
   http://www.sebastian-bergmann.de

 bonn.phpug.de | www.php.net | www.phpOpenTracker.de | www.titanchat.de

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] is_reference() ?

[Zeev Suraski]

At 22:36 21/3/2001, Björn Schotte wrote:
>Hi,
>
> > It's not really possible right now due to the way Zend engine works.
>
>So it would be better to reopen the bug reports
>which considered the unset() issue?

unset() is consistent with the way it is defined - it removes a certain 
symbol from the namespace.  If you refer to the fact you use unset() to 
unset not only the symbol itself, but also all other symbols that reference 
to the same value - that's true, but that's just the way it is...  You can 
assign null to them instead.

Zeev


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] is_reference() ?

[Björn Schotte]

Hi Zeev,

> >inconsistencies with unset($foo) and unset($bar["bla"])
> >(the latter works, the former not))
> Huh?  Both work...?

Here it is in detail:

http://www.php.net/bugs.php?id=8937
http://www.php.net/bugs.php?id=8972

> This has been discussed before (as far as I recall).  The engine may 
> convert certain variables to be references on the fly, without the user 
> requesting it.  So, is_reference() won't mean much to end users.

In case of the former bug reports, I think it would
mean much.

-- 
Björn Schotte  [EMAIL PROTECTED]
http://rent-a-phpwizard.de/   [EMAIL PROTECTED]

  PHP Schulungen, Softwareentwicklung, Coaching  

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9905 Updated: Error on www.php.net

[sniper]

ID: 9905
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Closed
Status: Bogus
Bug Type: Documentation problem
Assigned To: 
Comments:



Previous Comments:
---

[2001-03-21 15:07:16] [EMAIL PROTECTED]
This is a minor issue, but the date at the top right of www.php.net is inconsistant.  
On alternating sections, it is one day behind. Thus on documentation, support, and 
links, it says it is yesterday, but on downloads, faq, and reporting bugs, it is the 
right day.

I don't know if this is the right place for this, but I could find another email 
address to report it.

Mark

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9905&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] is_reference() ?

[Zeev Suraski]

At 22:39 21/3/2001, Björn Schotte wrote:
>Hi Zeev,
>
> > >inconsistencies with unset($foo) and unset($bar["bla"])
> > >(the latter works, the former not))
> > Huh?  Both work...?
>
>Here it is in detail:
>
>http://www.php.net/bugs.php?id=8937
>http://www.php.net/bugs.php?id=8972

Ok, as I thought, it has to do with the fact the unset()'ing a variable 
won't unset any references to it.  It (the way globals/statics work) is a 
changed behavior from PHP 3.0, but it's an intended behavior and isn't 
considered a bug.

Zeev


--
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9874 Updated: bicubic jpg resize

[sniper]

ID: 9874
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: *Graphics related
Assigned To: 
Comments:

submitted twice.


Previous Comments:
---

[2001-03-20 11:07:51] [EMAIL PROTECTED]
Someone posted a bicubic jpeg resize in the help list for imagecopyresized function 
and it would be nice if this was built into the regularly compiled php version...

It's really nice since the quality of the images are SO much nicer.

Thanks,
Noah

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9874&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] is_reference() ?

[André Langhorst]

> Here it is in detail:
> 
> http://www.php.net/bugs.php?id=8937
> http://www.php.net/bugs.php?id=8972

The fact that people think having found a bug doesn't justify the introduction
of a confusing, meaningless function IMHO

after reading stas' reference docs you should have understood that 
unset() does not kick the variable into space, it just removes access to 
it and it may be existent in some scope anyway (if referenced before), 
the $var=NULL "trick" (it really is no trick if you understand how 
references work and are aware of the equivalence regarding a 
non-existing variable and one set to NULL)

thus is_reference() never makes sense, you simply cannot spot the reference

andré




-- 
· André Langhorstt: +49 331 5811560 ·
· [EMAIL PROTECTED]  m: +49 173 9558736 ·
* PHP Quality Assurance  http://qa.php.net  *


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] is_reference() ?

[André Langhorst]

> thus is_reference() never makes sense, you simply cannot spot the reference

note:

what *could* make sense for debugging is a function like 
are_identical($foo,$foo2) which compares if they both belong to the same 
zval_struct (you could even write this one is userland, by saving the 
original value, assigning a new value and watch if the other one changes)

I do not have thoroughly thought about it, but I *could* imagine that it 
could be useful to recognize two variables as being the same, while it 
would not be possible using ===

two avoid further trouble it should be not be named, if introduced, with 
the word "reference" in it and ==& or &== or whatever is ugly and 
misleading to,  is ridiculously, maybe we would have == some 
day to test if two variables are one the same planet... ;)
maybe __is_identical(), __identical() or another ugly name to prevent 
standard users from using it


andré




-- 
· André Langhorstt: +49 331 5811560 ·
· [EMAIL PROTECTED]  m: +49 173 9558736 ·
* PHP Quality Assurance  http://qa.php.net  *


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] RE: PHP 4.0 Bug #9636 Updated: error message

[Smith, Robert W.]

Before doing that I tried making the directory cgi executable and adding 
"#!/usr/local/bin/php" to the scripts.  That seemed to do the trick athough
I didn't think this was the GCI version.

Here is the output:
http://www.lib.ecu.edu/st/php/test.php

As far as I can tell, I'm set up for mySQL support

Thanks for your help.

-Original Message-
From: Bug Database [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 21, 2001 2:41 PM
To: [EMAIL PROTECTED]
Subject: PHP 4.0 Bug #9636 Updated: error message


ID: 9636
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Compile Failure
Assigned To: 
Comments:

Get the latest CVS snapshot (from today) add --enable-debug into your
configure line and configure, 'make clean ; make ; make install'

And then generate a GDB backtrace of the crash.
(as it most likely is crashing)
And if it happens with specific script, add the (shortest)
possible script into this bug report that can be used
to reproduce the crash.

--Jani




Previous Comments:
---

[2001-03-08 19:09:37] [EMAIL PROTECTED]
Please try the latest CVS snapshot from http://snaps.php.net/

--Jani


---

[2001-03-08 15:03:06] [EMAIL PROTECTED]
For Netscape Enterprise Server configuration:

After installing all the necessary packages and running
"./configure --with-mysql=/usr/local/mysql --with-nsapi=
/opt/netscape/suitespot --enable-track-vars --enable-libgcc"

When attempting to run "make" I get the following:

# make
Making all in Zend
Making all in Zend
/bin/sh ../libtool --silent --mode=compile c++ -DHAVE_CONFIG_H -I. -I.
-I../main
   -D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT
-DXML_BYTE
_ORDER=21 -I../TSRM  -g -O2 -pthreads -c zend_language_scanner_cc.cc
In file included from zend_language_scanner_cc.cc:2571:
zend_operators.h: In function `int is_numeric_string(char *, int, long int
*, do
uble *)':
zend_operators.h:84: implicit declaration of function `int finite(...)'
make[1]: *** [zend_language_scanner_cc.lo] Error 1
make[1]: Leaving directory `/usr/local/php-4.0.4pl1/Zend'
make: *** [all-recursive] Error 1
#

Running gcc-2.95_2

Thanks,
Bob Smith
Computer Systems Administrator
East Carolina University
[EMAIL PROTECTED]
(252) 328-0421

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9636&edit=2

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]