Re: [PHP-DEV] Tiny leak with append file?

[Zeev Suraski]

Are you running the latest CVS, or is there any chance it's a snapshot from 
a few days ago?

At 18:45 31-08-01, Wez Furlong wrote:
>I'm seeing this in the output of my cron jobs:
>
>./zend_execute.c(1434) :  Freeing 0x087FD474 (1 bytes), script=dodeletes.php
>Last leak repeated 10893 times
>
>The number of repeats is proportional to how much work the scripts need
>to do; it varies from 1 up to whatever (like 10893!).
>
>If I put "exit();" at the end of my script (or anywhere else in the script),
>I don't see the leak.
>
>I don't use anything that might eval(), AFAICT.
>
>Strange.
>
>--Wez.
>
>
>
>--
>PHP Development Mailing List <http://www.php.net/>
>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 <http://www.php.net/>
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: problems with ob_gzhandler

[Zeev Suraski]

It should be gone with the latest CVS

At 17:55 31-08-01, Wez Furlong wrote:
>On 08/31/01, "Zeev Suraski" <[EMAIL PROTECTED]> wrote:
> > BTW, any chance you're using trans_sid?  (can you check if
> > php_session_start_output_handler() ends up being called for some reason?)
>
>I'm not using trans_sid but I am using sessions.
>My scripts generally do this:
>
>if (!session_is_registered("sess")) {
> $sess = array();
> session_register("sess");
>}
>
>if (!broken_browser())
> ob_start("ob_gzhandler");
>else
> ob_start();
>
>The session handler is a custom handler against a mysql db.
>
>If the scripts need to redirect, they do this:
>
>session_write_close(); // Concurrency problems arise otherwise
>header("Location: ...");
>exit();
>
>Hope that helps; I dont have time to get in there with a debugger
>right now.
>
>--Wez.
>
>
>--
>PHP Development Mailing List <http://www.php.net/>
>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 <http://www.php.net/>
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: problems with ob_gzhandler

[Zeev Suraski]

The bugs (two different ones) and their symptoms should be gone now.

At 15:49 31-08-01, Thies C. Arntzen wrote:
>On 31 Aug 2001 15:27:11 +0300, Zeev Suraski wrote:
> > BTW, any chance you're using trans_sid?  (can you check if
> > php_session_start_output_handler() ends up being called for some reason?)
>
>it does get called. but the session is already there (cookie based) so
>there's no reason to start the trans-sid thingie. somehow the logic in
>session.c:917 seems wrong.
>
>re,
>tc
>
>
>
> >
> > At 15:16 31-08-01, Thies C. Arntzen wrote:
> > >hi,
> > >i have "output_handler=ob_gzhandler" in my php.ini
> > >
> > >and just found those messages in my apache error_log:
> > >[Fri Aug 31 13:20:47 2001]  Script:  '/home/thies/shop/login.php'
> > >---
> > >/home/thies/devel/php4/main/output.c(240) : Block 0x0821D270 status:
> > >Beginning:  Overrun (magic=0x402640D8, expected=0x7312F8DC)
> > >   End:  Unknown
> > >
> > >which is a BadThing(tm). i'm running HEAD - haven't tried PHP_4_0_7.
> > >
> > >'cause i don't have the time right now to dig myself i though that
> > >reporting it is nearly half as good as fixing it;-)
> > >
> > >re,
> > >tc
> >
> > --
> > Zeev Suraski <[EMAIL PROTECTED]>
> > CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/
> >
>
>
>
>--
>PHP Development Mailing List <http://www.php.net/>
>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 <http://www.php.net/>
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: problems with ob_gzhandler

[Zeev Suraski]

At 15:49 31-08-01, Thies C. Arntzen wrote:
>On 31 Aug 2001 15:27:11 +0300, Zeev Suraski wrote:
> > BTW, any chance you're using trans_sid?  (can you check if
> > php_session_start_output_handler() ends up being called for some reason?)
>
>it does get called. but the session is already there (cookie based) so
>there's no reason to start the trans-sid thingie. somehow the logic in
>session.c:917 seems wrong.

Ok, that's what I suspected.  I'll try to look at it now.

Zeev


-- 
PHP Development Mailing List <http://www.php.net/>
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: problems with ob_gzhandler

[Zeev Suraski]

BTW, any chance you're using trans_sid?  (can you check if 
php_session_start_output_handler() ends up being called for some reason?)

At 15:16 31-08-01, Thies C. Arntzen wrote:
>hi,
>i have "output_handler=ob_gzhandler" in my php.ini
>
>and just found those messages in my apache error_log:
>[Fri Aug 31 13:20:47 2001]  Script:  '/home/thies/shop/login.php'
>---
>/home/thies/devel/php4/main/output.c(240) : Block 0x0821D270 status:
>Beginning:  Overrun (magic=0x402640D8, expected=0x7312F8DC)
>   End:  Unknown
>
>which is a BadThing(tm). i'm running HEAD - haven't tried PHP_4_0_7.
>
>'cause i don't have the time right now to dig myself i though that
>reporting it is nearly half as good as fixing it;-)
>
>re,
>tc

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


-- 
PHP Development Mailing List <http://www.php.net/>
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: problems with ob_gzhandler

[Zeev Suraski]

That's the 2nd report of the same thing - but I'll need a much more 
definite report in order to do something about it :I

At 15:16 31-08-01, Thies C. Arntzen wrote:
>hi,
>i have "output_handler=ob_gzhandler" in my php.ini
>
>and just found those messages in my apache error_log:
>[Fri Aug 31 13:20:47 2001]  Script:  '/home/thies/shop/login.php'
>---
>/home/thies/devel/php4/main/output.c(240) : Block 0x0821D270 status:
>Beginning:  Overrun (magic=0x402640D8, expected=0x7312F8DC)
>   End:  Unknown
>
>which is a BadThing(tm). i'm running HEAD - haven't tried PHP_4_0_7.
>
>'cause i don't have the time right now to dig myself i though that
>reporting it is nearly half as good as fixing it;-)
>
>re,
>tc

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


-- 
PHP Development Mailing List <http://www.php.net/>
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] emalloc_rel()

[Zeev Suraski]

Yeah,  but you have to make sure that it gets passed the right arguments.
Your 'hosting' function(s) must have filename&lineno info passed to them 
(i.e., ZEND_FILE_LINE_DC in the prototype).
The allocation function should have should have 'ZEND_FILE_LINE_DC 
ZEND_FILE_LINE_ORIG_DC' in its prototype.
Then, calling emalloc_rel() should work fine.

Zeev

At 10:36 31-08-01, Robin Ericsson wrote:
>I'm trying to get emalloc_rel() working in a extension I wrote, but I
>get undefined references to __zend_filename, and I can't find that
>defiend anywhere in the source.
>
>Is it even possible to get emalloc_rel() working in a extension? I have
>the need for it, as the extension is written in c++ and overloaded
>emalloc/efree to be able to detect memoryleaks.
>
>
>
>--
>Robin Ericsson
>
>
>
>--
>PHP Development Mailing List <http://www.php.net/>
>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 <http://www.php.net/>
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] Returning a string from an executed script?

[Zeev Suraski]

At 19:01 29-08-01, Rasmus Lerdorf wrote:
> > We could improve zend_execute_scripts() to take an optional zval * to hold
> > the return value, it's already quite ready for this kind of thing.
>
>That would work perfectly.  Think this could be done sooner rather than
>later?  ie. in the current engine?

Yup, it should be doable.  I added it to my TODO.

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] [PATCH] Zend/zend_alloc.c

[Zeev Suraski]

At 18:45 29-08-01, George Schlossnagle wrote:
> > > At 14:57 29-08-01, Walter Franzini wrote:
> > > > From the extension (the user of kernel services) pov I must disagree.
> > >>But obviusly I'missing something :-)
> > >
> > > I don't see why there's a difference.
> >
> > Maybe the difference is not ZE vs. extension but internal vs. external
> > data, where external means coming from the outside of PHP/Zend.
> >
> > If you try to allocate memory for data that come from the outside (the
> > browser, a db) you should fail gracefully: a malicious user can send
> > to your app a huge amount of data only to make it crash.
>
>This sort of checking should be done by the extension before you make the
>allocation, no?   You shoulnd't even be -trying- to allocate 2G of memory
>for an object in your extension (unless you really want to be, of course).
>Amongst other things allowing for this sloppiness only encourages people to
>further sloppiness, like not checking the return values of their
>malloc/emalloc call, which will almost certainly result in crashes when they
>return null and that pointer is sloppily passed to another routine without
>proper checking.  Failure to allocate should be a fatal error.

Sometimes it makes sense (but these cases are very rare).  For instance, 
some hashes that over-populate try to increase their lookup table size, so 
that they stay efficient - but if you try to allocate a bigger block and 
fail, it's quite alright to stay with the existing table size.  That's the 
only reason we added this ability to erealloc(), so they're really rare cases.

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: SEGFAULTs in apache

[Zeev Suraski]

Are you using sessions?  Output compression?  Your own output handler?
Cutting things down to something that reproduces the problem would be 
pretty essential here - the output buffering code is quite complex.

At 18:51 29-08-01, Wez Furlong wrote:
>I've managed to get things to run without segfaults (--enable-debug)
>but noticed this in my error log:
>
>---
>output.c(240) : Block 0x089807C0 status:
>Beginning:  Overrun (magic=0x401945F8, expected=0x7312F8DC)
>   End:  Unknown
>
>This is also with latest CVS, and the scripts without output buffering are
>the ones
>that were unaffected by the segfaults earlier.
>
>--Wez.
>
> > Program received signal SIGSEGV, Segmentation fault.
> > chunk_alloc (ar_ptr=0x401942c0, nb=3856) at malloc.c:2878
> > 2878malloc.c: No such file or directory.
> > (gdb) bt
> > #0  chunk_alloc (ar_ptr=0x401942c0, nb=3856) at malloc.c:2878
> > #1  0x4010883c in malloc () at malloc.c:2181
> > #2  0x40310b0d in _emalloc () at zend_alloc.c:330
> > #3  0x40310d27 in _erealloc () at zend_alloc.c:330
> > #4  0x40328fb2 in op_array_alloc_ops (op_array=0x8a3c024) at
> > zend_opcode.c:48
> > #5  0x40329028 in init_op_array () at zend_opcode.c:48
> > #6  0x4030ab07 in compile_file () at zend_language_scanner.c:5085
> > #7  0x403246db in execute () at ./zend_execute.c:959
> > #8  0x4031ff42 in execute () at ./zend_execute.c:959
> > #9  0x4031ff42 in execute () at ./zend_execute.c:959
> > #10 0x40330abe in zend_execute_scripts () at zend.c:371
> > #11 0x4033f984 in php_execute_script () at main.c:1243
> > #12 0x4033b2fe in apache_php_module_main () at sapi_apache.c:100
> > #13 0x4033bec0 in send_php (r=0x86ce280, display_source_mode=0,
> > filename=0x0)
> > at mod_php4.c:575
> > #14 0x4033bf33 in send_parsed_php (r=0x86ce280) at mod_php4.c:590
> > #15 0x8054405 in ap_invoke_handler ()
> > #16 0x8063dcc in process_request_internal ()
> > #17 0x80640ef in ap_internal_redirect ()
> > #18 0x409f4d9e in XkbChangeEnabledControls () from
> > /usr/X11R6/lib/libX11.so.6
> > #19 0x8054405 in ap_invoke_handler ()
> > #20 0x8063dcc in process_request_internal ()
> > #21 0x8063e31 in ap_process_request ()
> > #22 0x805d539 in child_main ()
> > #23 0x805d6cc in make_child ()
> > #24 0x805d7f1 in startup_children ()
> > #25 0x805dcc0 in standalone_main ()
> > #26 0x805e38f in main ()
> > #27 0x400cfa8e in __libc_start_main () at
> > ../sysdeps/generic/libc-start.c:93
> >
>
>
>--
>PHP Development Mailing List <http://www.php.net/>
>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 <http://www.php.net/>
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] [PATCH] Zend/zend_alloc.c

[Zeev Suraski]

At 18:35 29-08-01, Walter Franzini wrote:
>Zeev Suraski <[EMAIL PROTECTED]> writes:
>
> > At 14:57 29-08-01, Walter Franzini wrote:
> > > From the extension (the user of kernel services) pov I must disagree.
> >>But obviusly I'missing something :-)
> >
> > I don't see why there's a difference.
>
>Maybe the difference is not ZE vs. extension but internal vs. external
>data, where external means coming from the outside of PHP/Zend.
>
>If you try to allocate memory for data that come from the outside (the
>browser, a db) you should fail gracefully: a malicious user can send
>to your app a huge amount of data only to make it crash.

But it does not crash.  It exits, which is the safest thing you can do.

> >From the user point of view an application that exit without a message
>is crashed, no matter how controlled the shutdown is.
>
>Is this a reasonable scenario?

Given the fact that a failed malloc() can often mean that the situation is 
*really* bad, the best thing to do would be exiting.  Doing anything else, 
such as printing things out, etc., is dangerous, as it may result in a 
crash.  We can argue as to what to do in case we run out of memory - but 
what you were suggesting is not doing anything, and move the responsibility 
for the users of the memory manager.  No matter how I look at it, that's a 
bad thing.

>But
>
>"Ehi, I can't allocate the memory needed to store a refcount.  It's
>time to exit!!"
>
>seems reasonable to me.

Due to the reasons I gave in my previous letter, I disagree.

Zeev


-- 
PHP Development Mailing List <http://www.php.net/>
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] [PATCH] Zend/zend_alloc.c

[Zeev Suraski]

At 14:57 29-08-01, Walter Franzini wrote:
> From the extension (the user of kernel services) pov I must disagree.
>But obviusly I'missing something :-)

I don't see why there's a difference.

There may be a point in giving extension developers an _ex way to try and 
allocate memory, and fail gracefully (return NULL) in case of failure.  We 
already have this support in realloc(), we can add it to emalloc() if it's 
necessary.

Do you have a case where you want to try and allocate a chunk of memory, 
and do something special in case it fails (e.g., allocate a smaller 
block)?  If so, we can try to come up with a solution.

My main point is that there's a very strong motivation to take away the 
responsibility of what happens in case of a memory failure away from the 
API user, and take care of it in a centralized way in the memory 
manager.  It's safer (no possibility of memory allocation failures causing 
crashes) and it avoids redundant coding.  If this behavior is unsuitable in 
certain cases, we should address these cases, rather than cut this safety 
net to pieces.

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] [PATCH] Zend/zend_alloc.c

[Zeev Suraski]

At 12:38 29-08-01, Walter Franzini wrote:
>Stanislav Malyshev <[EMAIL PROTECTED]> writes:
>
>[...]
>
> > WF>> I faced this problem using odbc with Solid.  SQLColAttributes can
> > WF>> return very big number (2147483647) when you ask for
> > WF>> SQL_COLUMN_DISPLAY_SIZE of a LONG VARCHAR and obviously my computer
> > WF>> does not have enough virtual memory.
> >
> > It is not always a wise idea to use MAX_SIZE kind of constants to allocate
> > memory. Some of them can indeed be huge. You should fix you code to not
> > use such constants for memory allocation.
>
>If you look better at the patch, the current php implementation
>(php-4.0.6 and current cvs) uses the MAX_SIZE approach and I try to
>lower this number to a more reasonable value.

I'm not sure what you mean here.  Several things:

- A crash is not an organized shutdown, no matter how you look at 
it.  Different operating systems treat it in different ways, and none of 
them is considered a good way of shutting down.
- By default, PHP builds without memory_limit enabled.  A failure would 
only occur if we actually run out of memory, and then, simply put, we're 
screwed anyway, and the best thing we can do is try to shut down as nicely 
as possible.
- If you enable memory_limit, when the program reaches it, the engine 
schedules a shutdown - a very organized one. The only situation in which an 
exit() would occur is if during the shutdown, the memory consumption 
continues to grow beyond 1MB of the memory limit.

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] Returning a string from an executed script?

[Zeev Suraski]

We could improve zend_execute_scripts() to take an optional zval * to hold 
the return value, it's already quite ready for this kind of thing.

At 10:00 29-08-01, Rasmus Lerdorf wrote:
>Mostly a Zend question I guess, but I am playing with having PHP handle
>other phases of the Apache request_rec and currently have working code
>that lets a PHP script get run during the uri translation hook.  This is a
>nice one to start with because it can really open up some cool things that
>can otherwise only be done through an ErrorDocument handler, and even then
>you are somewhat limited in what you can do there.
>
>What I am not sure of is how to communicate the new translated uri back to
>the calling handler function in mod_php4.c.  Right now I have:
>
>php_admin_value uri_handler /full/path/uri.php
>
>And I have some code that takes that uri_handler script filename and
>trickles it down to a call to:
>
>   zend_execute_scripts(ZEND_REQUIRE TSRMLS_CC, 1, primary_file);
>
>Where primary_file is:
>
> primary_file.type = ZEND_HANDLE_FILENAME;
> primary_file.handle.fd = 0;
> primary_file.filename = uri_handler;
> primary_file.opened_path = NULL;
> primary_file.free_filename = 0;
>
>That all seems to work fine and the PHP executes at the required stage
>during the request handling.  But what should uri.php look like?
>I think something like this would be nice:
>
>  return '/foo'.$REQUEST_URI;
>   ?>
>
>Obviously a simple handler, but it would take a request like
>http://php.net/blah.php and actually cause http://php.net/foo/blah.php to
>be opened up during the content parsing request_rec phase.
>
>I don't see a way to currently do such a return and get at the returned
>value after the call to zend_execute_scripts().  Any suggestions?
>
>-Rasmus
>
>
>--
>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]

Re: [PHP-DEV] [PATCH] Zend/zend_alloc.c

[Zeev Suraski]

There's a big difference between an undefined behavior which may result in 
a crash, and an organized shutdown.  The former is dangerous, the latter is 
not.
There are some parts of code that don't rely on this, from the times when 
it wasn't true, but it doesn't cause any problem, so there's no reason to 
change it urgently.

Zeev

At 09:54 29-08-01, Walter Franzini wrote:
>Stanislav Malyshev <[EMAIL PROTECTED]> writes:
>
> > JG>> I disagree with this patch. The scenario of not being able to
> > JG>> allocate memory is a fatal error, and the only appropriate
> > JG>> response for php is to exit. If you need other behavior use
> > JG>> pemalloc( which calls malloc if set persistant ).
> >
> > Actually, there's a lot of code in PHP that is based on the assumption
> > that emalloc never fails. If emalloc can return NULLs, all this code
> > should be rewritten. I do not see any point in it and agree with Jason.
>
>You are right, but this "feature" (emalloc never fails) is
>undocumented and both php and zend are full of code that just check the
>emalloc return value.  You can find some example also in zend_alloc.c.
>
>Changing emalloc to return NULLs does not modify the program
>behaviour: you (probably) receive a SIGSEGV from the emalloc caller
>and the execution terminate.  I can't see a big difference in this
>case, but if you check for NULL you can fail gracefully.
>
>Ciao
>--
>Walter Franzini, e-mail: [EMAIL PROTECTED]
>SysNet, Via Digione 8, 27100 Pavia - Italy
>
>
>--
>PHP Development Mailing List <http://www.php.net/>
>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 <http://www.php.net/>
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] python dictionary-like % (percent) substitution in php (was: Good idea in % (percent) substitutions in string)

[Zeev Suraski]

At 16:35 28-08-01, Jo Giraerts wrote:
>This is already possible in php, though with the following simple
>function..
>
>// function to read a file with php-vars in as a string
>// $predefined_vars: an array ("varname" => "value"). all the
>// variablenames defined in this array can be used in the bodyfile.
>// They will receive the respective values. This makes personalising
>// the mailes easier..
>function file_as_body($filename, $predefined_vars)
>{
>   $ar = file($filename);
>   extract($predefined_vars);
>
>   foreach ($ar as $number => $line)
>   {
>  eval("\$ar2[] = \"$line\";");

Yikes, is there any reason that's not simply $ar2[] = $line;?

Anyway, how does it give the same functionality as the suggest aprintf()?

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] python dictionary-like % (percent) substitution in php (was: Good idea in % (percent) substitutions in string)

[Zeev Suraski]

I think that's a pretty good idea.

At 13:25 28-08-01, --- wrote:
>I have seen that in php there isn't nothing similar to dictionary
>substitution in python.
>(a dictionary is an array with string keys, like hash in perl)
>
>This change consist in adding two functions ("a" stay for "array"):
>aprintf(string format, array dict) -- like printf, print the result
>saprintf(string format, array dict) -- like sprintf, return the result
>
>It works like this (written in php-like language):
>
>format -> "my name is %(name)s and i'm %(age)s"
>dict -> array( name=>"tom", age=> "eighteen" );
>
>(in php, unlike python, is possible to make an array with both string and
>number indices, so the format can be also %(2)s,...)
>
>aprintf(format,dict) -- print "my name is tom and i'm eighteen"
>saprintf(format,dict) -- return "my name is tom and i'm eighteen"
>
>in python, these substitutions are very useful, especially in cgi
>programming, for making templates from text files, in php could be
>useful in, for example, language customisation, or message formatting,
>etc...
>
>An example:
>if ($lang == "it")
>   define("MESSAGE","il %(animal)s %(color)s sta %(action)s %(target)s");
>else
>   define("MESSAGE","the %(color)s %(animal)s is %(action)s");
>
>aprintf(MESSAGE,array(animal=>"cobra",color=>"green",action=>"eating",target
>=>"mouse"));
>// if the %(target)s isn't found, is ignored.
>
>
>(the "s" terminator could be substituted with other letters, like d for
>numbers, etc...)
>
>This approach has several advantages over something like this:
>"the $color $animal is $action"
>because in this phrase, variables are substituted when the parser execute
>it, and in this case:
>"the %(color)s %(animal)s is %(action)s"
>parameters are substituted only when the phrase is parsed with a specialized
>function like aprintf
>
>
>
>I think that this is a good idea and could save a lot of time when the
>program need to be as modular as possible.
>
>
>Federico Marani
>[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 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 /ext/standard basic_functions.c incomplete_class.c php_incomplete_class.h var.c /ext/wddx wddx.c

[Zeev Suraski]

At 11:37 28-08-01, Walter Franzini wrote:

>[sorry, my English is bad]
>
>Zeev Suraski <[EMAIL PROTECTED]> writes:
>
>[...]
>
> > Why?  Whatever extension you use on your box, put them in the php.ini.
> > dl() is never a better option.
> >
> > Zeev
>
>An example not solvable using php.ini:
>
>At SysNet, we access dbms only with odbc_* functions using (for
>different apps on the same server) solid and IBMdb2.
>
>We compile ext/odbc/php_odbc.c as solid.so and ibmdb2.so and load the
>right module using dl ().  Using php.ini is not feasible because this
>lead to multiple function definition.
>
>I think a similar situation may arise with multiple xslt backend, they
>must export the same API but could provide different features (or
>bugs) so you must use xslt1 for app1 and xslt2 for app2.
>
>Please don't drop dl () :-)

We're not dropping it :)  It works just as well as it did until now, which 
is not too well.  Solving the problems that arise by deprecating dl() 
(improving the ODBC module, for instance) are much easier than solving the 
problems that fixing the broken things about dl().  Right now, we're simply 
keeping the status-quo.

Zeev


-- 
PHP Development Mailing List <http://www.php.net/>
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] contributing extensions?

[Zeev Suraski]

At 08:10 28-08-01, George Schlossnagle wrote:
>Ok,
>
>I have a php interface to the spread group communication toolkit client 
>api.  Hard to say how wide it's audience would be, but it's very useful 
>for creating distributed applications (it was written to facilitate some 
>distributed logging and distributed filesystem caching needs).  Code 
>available from
>http://www.lethargy.org/~george/php_spread/php_spread-0.1.tar.gz

If you think it would have a significant audience (i.e., more than you :) 
then we can add it in.

>Dan Cowgill and I have a tracing/profiling/debugging extension which we 
>would be quite interested in having included in php.  Code available from 
>http://apc.communityconnect.com/sources/apd-cvs.tar.gz
>
>Also, there is our APC caching project, which has become pretty mature now 
>.  It has a relatively large following and I think it would benefit php to 
>have a free bundled compiler cache with it (not to mention benefit from 
>the much larger developer base).  Code available from 
>http://apc.communityconnect.com/source/apc.tar.gz.

Due to the mutual exclusive nature of zend_extension's (extensions that 
modify the engine's behavior), we don't store these inside the PHP source 
tree.  As it came up in the past, we can (and probably should) put up a 
directory of such extensions on php.net.  All we need is someone to 
volunteer to do that.

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] MFH'ing PEAR changes

[Zeev Suraski]

At 11:08 28-08-01, Stig S. Bakken wrote:
>Any objections against me MHF'ing some non-critical stuff in php4/pear?
>It's so long between each PHP release now that the PEAR stuff that comes
>with PHP is usually outdated by the day of the release. :-P

I don't think PEAR gets thoroughly tested during the RC cycle (am I 
wrong?), so I think it should be fine.

I think we should go with RC2 soon.  The flow of patches is pretty slow 
right now.

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] A couple of session issues

[Zeev Suraski]

At 19:00 27-08-01, Thies C. Arntzen wrote:
> > You lost your caps too? :)
>
>some time ago already;-) didn't you notice?

No, I hadn't noticed.  I'll help you look for them in November :)

>if you are on a site that uses trans-sid for sessions the HTTP_REFERER
>on the next visited site will contain your session-id.

Ah, makes sense.  That's indeed not a very cool thing.


> > trans_sid, by using the existing php.ini setting.
>
>makes sense - i just don't want a new & changed default behaviour of
>PHP. if i run a cookie based session and for some weird reason i have a
>stray character in one of my pages i do not want PHP to switch to
>trans-sid - i want to get notified ("Headers already sent") and fix my
>bug.

Well, you kind of convinced me that it's not a very good idea.  The danger, 
combined with the fact that people won't expect this to happen, combined 
with the fact it's not a very 'clean' thing anyway, combined with the fact 
that trans_sid itself is on by default (it no longer requires 
--enable-trans-sid), this whole mess together sums up to 'not a very good 
idea'.

Thanks for the info :)

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] A couple of session issues

[Zeev Suraski]

At 13:40 27-08-01, Thies C. Arntzen wrote:
>On 27 Aug 2001 01:33:46 +0300, Zeev Suraski wrote:
> > The other issue is a suggestion I want to pitch - right now, if sessions
> > are started after the headers are already sent, we'll get a nice
> > headers-already-sent error.  If we have trans_sid enabled (which we will
> > most probably, from now on) - we can check whether the headers are already
> > sent, and if they are, move to use trans_sid instead.  Any comments?
> >
>i tend not to do that. trans-sid is a very different thing from cookies
>(session id's are populated to foreign-sites via HTTP_REFERRER). i don't 
>think
>we should default to it. developers should decide themself if they want 
>trans-sid
>or not.

You lost your caps too? :)

I'm not sure what you meant in the HTTP_REFERRER issue - can you explain 
it?  At any rate, developers still can decide whether or not they want 
trans_sid, by using the existing php.ini setting.

Zeev


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] A couple of session issues

[Zeev Suraski]

One thing I couldn't get to the bottom of is PS(define_sid) and the 
define_sid logic in php_session_start().  I understand the code, but I 
couldn't understand why we define SID in certain cases to contain valid 
data, and sometimes just an empty string.  It's also being used in 
session_adapt_uris() later.

The other issue is a suggestion I want to pitch - right now, if sessions 
are started after the headers are already sent, we'll get a nice 
headers-already-sent error.  If we have trans_sid enabled (which we will 
most probably, from now on) - we can check whether the headers are already 
sent, and if they are, move to use trans_sid instead.  Any comments?

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-CVS] cvs: php4 /ext/session php_session.h session.c /ext/standard url_scanner_ex.c url_scanner_ex.re

[Zeev Suraski]

It's basically all a part of the same title.

What I did is de-coupling of the session trans_sid code and the output 
code.  The session module now uses chunked output buffering, and has no 
special cases in the output layer.  The advantages to doing that are:

- Faster performance (theoretical, I haven't actually tested it)
- Allows using trans-sid in conjunction with other output buffering 
features, such as ob_start(), output compression, and so on.

Zeev

At 01:12 27-08-01, Rasmus Lerdorf wrote:
>Hey, could you summarize your changes to trans_sid and the session sutff?
>I'm losing track with all these patches...
>
>On Mon, 27 Aug 2001, Zeev Suraski wrote:
>
> > zeev  Sun Aug 26 20:23:55 2001 EDT
> >
> >   Modified files:
> > /php4/ext/session php_session.h session.c
> > /php4/ext/standardurl_scanner_ex.c url_scanner_ex.re
> >   Log:
> >   More fixes and refinements
> >
> >

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


-- 
PHP Development Mailing List <http://www.php.net/>
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: How to make Thread Safety work (ZTS,TSRMLS) (was: Re: [PHP-CVS] cvs: php4 /main streams.c )

[Zeev Suraski]

At 00:23 27-08-01, Jeroen van Wolffelaar wrote:
>[Changed subject, I missed this thread until now because of it...]
>
>I assume this difference between 1&2 and 3 is _strictly_ performance, and
>_nothing_ else?

Well, it's also results in shorter code (there were plenty of functions 
that used both ELS, CLS, PLS and SLS, so their prototypes looked like ... 
ELS_DC CLS_DC PLS_DC SLS_DC, which was a mess).  It's performance and 
cleanliness.

>And a note for others: You don't need TSRML* in every function, but you do
>need it if you use:
>- Global variables, like BG(...) & co.

Note that most of the callbacks in the engine and in PHP now accept TSRMLS, 
so you don't need to fetch it (including internal functions, 
start/shutdown/activation/deactivation, etc.)

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] Anybody tested the Apache module recently?

[Zeev Suraski]

IIS and Apache, roughly 50/50...

At 23:07 26-08-01, Adam Dickmeiss wrote:
>Zeev,
>
>how do you test before commit? I mean, what web server do you use
>for development?
>
>-- Adam
>
>On Sun, Aug 26, 2001 at 02:48:14AM +0300, Zeev Suraski wrote:
> > I think that was some breakage I was responsible for (I committed a fix
> > about 30 minutes later, only apparently I never actually finished editing
> > the commit message, so it never left my machine).
> >
> > It should be fixed now.  Please let me know if it isn't.
> >
> > Zeev
> >
> > At 02:43 26-08-01, Rasmus Lerdorf wrote:
> > >It seems to have completely broken as of a CVS update of a few minutes
> > >ago.  Most of the time I get no output, but sometimes I get a very very
> > >long row of ZZ's or sometimes I get
> > >ZZZ?Ì?*Z?Ì?*Z
> > >
> > >Repeatedly loading a phpinfo() tends to toggle back and forth.  Single
> > >stepping through things looks normal.  zif_phpinfo() is getting called and
> > >everything looks fine.  So it is something lower level.  Output bufferring
> > >changes messing things up?
> > >
> > >relevant php.ini settings:
> > >
> > >output_buffering= Off
> > >output_handler  =
> > >implicit_flush  = Off
> > >zlib.output_compression = Off
> > >
> > >Same thing happens on a simple echo "Hello World" script.
> > >An strace on that shows:
> > >
> > >{sin_family=AF_INET, sin_port=htons(42216),
> > >sin_addr=inet_addr("127.0.0.1")}}, [16]) = 3
> > >rt_sigaction(SIGUSR1, {SIG_IGN}, {0x8074490, [], SA_INTERRUPT|0x400},
> > >8) = 0
> > >getsockname(3, {sin_family=AF_INET, sin_port=htons(80),
> > >sin_addr=inet_addr("127.0.0.1")}}, [16]) = 0
> > >setsockopt(3, SOL_TCP, TCP_NODELAY, [1], 4) = 0
> > >alarm(300)  = 0
> > >read(3, "GET /t.php HTTP/1.0\r\nConnection:"..., 4096) = 334
> > >rt_sigaction(SIGUSR1, {SIG_IGN}, {SIG_IGN}, 8) = 0
> > >time(NULL)  = 998782781
> > >alarm(300)  = 300
> > >alarm(0)= 300
> > >stat64("/home/rasmus/phpweb/t.php", {st_mode=S_IFREG|0664, st_size=30,
> > >...}) = 0
> > >alarm(300)  = 0
> > >umask(077)  = 022
> > >umask(022)  = 077
> > >setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={30, 0}}, NULL) = 0
> > >rt_sigaction(SIGPROF, {0x402102b0, [PROF], SA_RESTART|0x400},
> > >{0x402102b0, [PROF], SA_RESTART|0x400}, 8) = 0
> > >rt_sigprocmask(SIG_UNBLOCK, [PROF], NULL, 8) = 0
> > >getcwd("/usr/local/home/rasmus/phpweb", 4095) = 30
> > >chdir("/home/rasmus/phpweb")= 0
> > >open("/home/rasmus/phpweb/t.php", O_RDONLY) = 4
> > >getcwd("/usr/local/home/rasmus/phpweb", 4095) = 30
> > >lstat64("/home", {st_mode=S_IFLNK|0777, st_size=15, ...}) = 0
> > >readlink("/home", "/usr/local/home", 4095) = 15
> > >lstat64("/usr", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> > >lstat64("/usr/local", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> > >lstat64("/usr/local/home", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0
> > >lstat64("/usr/local/home/rasmus", {st_mode=S_IFDIR|0777, st_size=12288,
> > >...}) = 0
> > >lstat64("/usr/local/home/rasmus/phpweb", {st_mode=S_IFDIR|0755,
> > >st_size=4096, ...}) = 0
> > >lstat64("/usr/local/home/rasmus/phpweb/t.php", {st_mode=S_IFREG|0664,
> > >st_size=30, ...}) = 0
> > >ioctl(4, TCGETS, 0xbfffe110)= -1 ENOTTY (Inappropriate ioctl
> > >for device)
> > >fstat64(4, {st_mode=S_IFREG|0664, st_size=30, ...}) = 0
> > >mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
> > >= 0x40018000
> > >read(4, "\n", 8192) = 30
> > >read(4, "", 4096)   = 0
> > >read(4, "", 8192)   = 0
> > >ioctl(4, TCGETS, 0xbfffd0d0)= -1 ENOTTY (Inappropriate ioctl
> > >for device)
> > >close(4)= 0
> > >munmap(0x40018000, 4096)= 0
> > >chdir("/usr/local/home/rasmus/phpweb")  = 0
> > &g

Re: [PHP-DEV] Crash in var_dump and print_r

[Zeev Suraski]

But it is not :)
It was a double meaning sentence I guess, what I meant that what was 
*supposed* to be a valid zval *, was in fact a NULL (which is not a valid 
zval *)


At 18:31 26-08-01, George Schlossnagle wrote:
>If NULL's a valid zval*, then both of thise routines need to be fixed to 
>handle null pointers.  Here's some patches:
>
>--- zend.c.orig Sun Aug 26 11:14:28 2001
>+++ zend.c  Sun Aug 26 11:20:22 2001
>@@ -199,6 +199,10 @@
>
>  ZEND_API void zend_print_zval_r_ex(zend_write_func_t write_func, zval 
> *expr, int indent)
>  {
>+   if(expr == NULL) {
>+   ZEND_PUTS(" (NULL)");
>+   return;
>+   }
> switch(expr->type) {
> case IS_ARRAY:
> ZEND_PUTS("Array\n");
>
>
>--- var.c.orig  Thu Aug 16 11:16:52 2001
>+++ var.c   Sun Aug 26 11:24:54 2001
>@@ -63,7 +63,10 @@
> if (level>1) {
> php_printf("%*c", level-1, ' ');
> }
>-
>+   if ((*struc) == NULL) {
>+   php_printf(" (NULL)");
>+   return;
>+   }
> switch ((*struc)->type) {
>     case IS_BOOL:
> php_printf("%sbool(%s)\n", COMMON, 
> Z_LVAL_PP(struc)?"true":"false");
>
>
>On Sunday, August 26, 2001, at 06:15 AM, Zeev Suraski wrote:
>
>>It looks like domxml is responsible here.  The hash table that's sent to 
>>it contains a NULL value, which should be a valid zval *...
>>
>>Zeev
>>
>>At 13:04 26-08-01, Joey Smith wrote:
>>>This may be due to the way domxml is doing things, but the test script
>>>in bug #10936 still creates a crash, and the backtrace points to
>>>zend_print_zval_r_ex...see attachment 1.
>>>
>>>Attachment 2 show that var_dump() gives more or less the same result.
>>>
>>>
>>>--
>>>PHP Development Mailing List <http://www.php.net/>
>>>To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>For additional commands, e-mail: [EMAIL PROTECTED]
>>>To contact the list administrators, e-mail: php-list-
>>>[EMAIL PROTECTED]
>>
>>--
>>Zeev Suraski <[EMAIL PROTECTED]>
>>CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/
>>
>>
>>-- PHP Development Mailing List <http://www.php.net/>
>>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 <http://www.php.net/>
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] Crash in var_dump and print_r

[Zeev Suraski]

It looks like domxml is responsible here.  The hash table that's sent to it 
contains a NULL value, which should be a valid zval *...

Zeev

At 13:04 26-08-01, Joey Smith wrote:
>This may be due to the way domxml is doing things, but the test script
>in bug #10936 still creates a crash, and the backtrace points to
>zend_print_zval_r_ex...see attachment 1.
>
>Attachment 2 show that var_dump() gives more or less the same result.
>
>
>--
>PHP Development Mailing List <http://www.php.net/>
>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 <http://www.php.net/>
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] Anybody tested the Apache module recently?

[Zeev Suraski]

My fault :I  I'm working on it.

At 02:54 26-08-01, Rasmus Lerdorf wrote:
> > It should be fixed now.  Please let me know if it isn't.
>
>Well, as of right now, it is still broken.  Or am I waiting for a commit?
>
>-Rasmus


-- 
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] Anybody tested the Apache module recently?

[Zeev Suraski]

 back to my libphp4.so build on Aug.13 built with exactly the same
>./configure flags makes it work again.
>
>Those flags are
>
>#! /bin/sh
>#
># Created by configure
>
>'./configure' \
>'--with-mysql=/usr' \
>'--with-gd=/home/rasmus/gd-2.0.1' \
>'--with-freetype-dir=/usr' \
>'--enable-gd-native-ttf' \
>'--enable-gd-imgstrttf' \
>'--with-jpeg-dir=/usr' \
>'--with-png-dir=/usr' \
>'--with-xpm-dir=/usr/X11R6' \
>'--enable-exif' \
>'--with-pdflib=/usr/local' \
>'--enable-inline-optimization' \
>'--with-xml' \
>'--with-calendar' \
>'--enable-wddx' \
>'--enable-sockets' \
>'--with-db3' \
>'--with-snmp' \
>'--with-openssl' \
>'--enable-debug' \
>'--with-config-file-path=/etc' \
>'--with-swf=/usr/local' \
>'--with-expat=' \
>'--with-pgsql' \
>'--with-zlib' \
>'--with-ldap' \
>'--with-sablot=/usr' \
>'--with-expat-dir=/usr' \
>'--with-imlib' \
>'--with-apxs=/usr/sbin/apxs' \
>"$@"
>
>
>
>
>--
>PHP Development Mailing List <http://www.php.net/>
>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 <http://www.php.net/>
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.ini-dist php.ini-recommended

[Zeev Suraski]

At 16:48 25-08-01, Jani Taskinen wrote:
>Better question is, do we really want to do this?
>This doesn't fix anything. It only breaks things.
>Second, this will make writing portable scripts harder.
>Yet another ini setting to be checked for..
>
>The only good way of doing this rand() -> mt_rand() change would
>have been my way (tm) which was rejected. ie. using the mt_* always.

I think that what Jeroen's doing is a good idea.  We're dealing with this 
issue in a too techie manner, and forget that most people just want a 
random number when they call rand().  I don't think it's too much to ask :)

If rand() gives them pseudo random numbers, or predictable random numbers, 
then it's (usually) not what they're looking for.  I guess it's not 
impossible that someone would actually rely on the fact that given the same 
seed, you get the same predictable series of random numbers, but it's 
fairly poor coding, and I don't think it's being used too often (far less 
often than plain random numbers are, anyway).  If somebody wants to get a 
predictable series, let him ask for it explicitly.

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] concatenating strings

[Zeev Suraski]

At 00:06 25-08-01, Peter Bowen wrote:
>I am getting a SIGSEGV with this function.  I am probably just missing
>something.  I was hoping for a function with the prototype
>
>strcatl(zval **z, char *s, int l);
>strcat(zval **z, char *s);
>
>Lacking those, I tried
>zval **data;
>/* call to zend_hash_find to set data */
>
>zval *tmp;
>MAKE_STD_ZVAL(tmp);
>ZVAL_STRINGL(tmp, s, l, 1);
>add_string_to_string(*data, *data, tmp);
>
>What am I missing?

Nothing I can see off hand.  Where is it crashing?
BTW, apparently add_string_to_string() will crash if the first string is 
empty (in the places it's being used in right now, the first string cannot 
be empty so this case is not checked).  Any chance your first string is empty?

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] concatenating strings

[Zeev Suraski]

Look at add_string_to_string().

At 04:14 24-08-01, Peter Bowen wrote:
>I am writing an extension, and trying to figure out how to append to an
>existing string.  I have a pointer to a zval that is a string, and a
>pointer to another string, along with the other string's length. I have
>looked for a ZEND_STRCAT macro, or something similar, but don't see
>anything.  What is the proper/best way to handle this?
>
>Thanks.
>Peter
>
>
>
>--
>PHP Development Mailing List <http://www.php.net/>
>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 <http://www.php.net/>
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] Branching ext/standard?

[Zeev Suraski]

At 00:15 23-08-01, Jeroen van Wolffelaar wrote:
> > What I would do in your case is:
> >
> > (a) Tag the relevant files as they are today (i.e., PRE_RAND_REDESIGN or
> > whatever)
> > (b) Commit your move-around changes
> > (c) Commit the real changes (can be done immediately after (b), as long as
> > it's separate)
>
>The real changes are not ready... and I didn't want to start with it until I
>know the move-around is okay, since I don't like to work for nothing.
>I'll commit the move-around changes then, but it will be broken, maybe even
>normal build, because it is EXPERMENTAL, and I didn't do much testing, it is
>simply not ready, it's about the idea.

Sigh.  Ok then.  Commit the broken changes to a branched ext/standard, but 
let's set a dead line to branching it back in, or killing it :)  I think 
that 2 or 3 days should be enough to call the shots...

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] Branching ext/standard?

[Zeev Suraski]

At 00:03 23-08-01, Jeroen van Wolffelaar wrote:
>Simply committing at once with: "rewrite everything that has to do with
>rand" won't be any useful. 80% of the diff is the moving of code, and only
>20% the real change. You also don't see what changed. Just as bad as mixing
>WS fixes with real fixes.

I don't think you would get too many comments if you commit to a branch either.

What I would do in your case is:

(a) Tag the relevant files as they are today (i.e., PRE_RAND_REDESIGN or 
whatever)
(b) Commit your move-around changes
(c) Commit the real changes (can be done immediately after (b), as long as 
it's separate)
(d) Cross your fingers :)

If we like it, the tree will be fixed quite quickly.  If we don't, we can 
revert easily.
I usually don't encourage people to commit changes that break the tree, but 
as we're not anywhere near a new release (that is, 4.0.7 already branched) 
having the tree broken for a few hours or even a couple of days under the 
'less-mainstream' configurations is not a complete disaster...

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] Branching ext/standard?

[Zeev Suraski]

At 23:48 22-08-01, Jeroen van Wolffelaar wrote:
>It involves basic_func*, *math*, *rand* and *array* files (* are wildcards,
>not exclamation markings) files. And of course Makefile too.
>And probably some others too. That makes quite a significant portion of that
>directory. It is way much easier to branch the whole dir...
>
>Currently it only compiles as non-ZTS, Linux stand-alone executable, and not
>much else, definitely not windows, ZTS, and as module. This will remain so
>for quite a time, I guess. That means that the main branch will be broken
>for those situations for quite a time, and I don't think that's a good idea.

If it's such a far reaching change, I suggest you simply send the diff the 
php-dev.  It should be enough to be a basis for a discussion on the 
proposed changes.  If we decide to go through with it, it should be 
committed to the main branch, and fixed so that it would work everywhere 
(or find a working solution to keep the tree in a working 
state).  Branching away for long periods in the hope of merging back in is 
not a good idea.

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] Branching ext/standard?

[Zeev Suraski]

At 23:37 22-08-01, [EMAIL PROTECTED] wrote:
>Hi,
>
>I've got an experimental beginning of the new rand functions ready. I think
>it's good if others can comment on it before it is finished, because the
>course can be changed now quite easily, but when it's all done, I don't feel
>much about doing that...

Do you need the branch the whole directory?

We usually (read: always) don't use branches for development, i.e., we 
don't use branches that are planned to eventually merge in.  That's because 
CVS's branch handling leaves a lot to be desired...  It may be ok in this 
case, where the chances of somebody else committing something that would 
clash with your changes are very slim, but I think you're better off 
branching just the file or couple of files which you're modifying.

>So, should I branch ext/standard under the name 'EXPERIMENTAL', or
>'RAND_CHANGE', or something else?

EXPERIMENTAL is way too general to be good for such a purpose...  I'd try 
and use a fairly descriptive name, which is unlikely to be used again in 
the future.

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] pif

[Zeev Suraski]

At 23:18 22-08-01, Andrei Zmievski wrote:
> > Is it a big deal?  No, but it can be useful and has no real drawbacks.
>
>Okay. But I'll be forced to pronounce phf as FF, so "FF_mysql_connect"..
>:)

Ok, one real drawback then ;)

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] pif

[Zeev Suraski]

At 23:09 22-08-01, Andrei Zmievski wrote:
>On Wed, 22 Aug 2001, Zeev Suraski wrote:
> > How about phf_, for PHP Helper Function?
> > I see a point in differentiating language level API functions (e.g. like
> > output buffering) and module-specific helper functions (e.g., like
> > php_mysql_do_connect()).
>
>Explain what the point is, then. I would assume that functions like
>php_mysql_do_connect() are scoped statically, so it shouldn't be a big
>deal that they have php_ prefix.

It's not about possible symbol clashes...
When debugging (or when reading code), it helps to know what's a part of 
the API and what isn't.  It also makes different types of prefix-based 
searching (e.g., gdb's completion, or emacs' search feature) a bit easier.

Is it a big deal?  No, but it can be useful and has no real drawbacks.

Zeev


-- 
PHP Development Mailing List <http://www.php.net/>
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] pif

[Zeev Suraski]

How about phf_, for PHP Helper Function?
I see a point in differentiating language level API functions (e.g. like 
output buffering) and module-specific helper functions (e.g., like 
php_mysql_do_connect()).

Zeev

At 22:57 22-08-01, Jeroen van Wolffelaar wrote:
> > I'm against that. Usually underscore-prefixed symbols are used by system
> > libraries and OS and we don't need to go in that direction. I'm also
> > against using pif_, because it's not an internal function that you are
> > naming, but rather, a helper one.
>
>I don't really have an opinion on this matter, I just wanted to know what to
>do. So you are suggesting to simply stick with php_ prefix and not doing
>anything else?
>
>Then I'll comply with that. In math.c, I saw that use of underscore as first
>letter, so that is not according to how it should be done, I assume.
>
>Thanks for clearing this up,
>
>Jeroen

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


-- 
PHP Development Mailing List <http://www.php.net/>
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] EXT_SKEL for Win32

[Zeev Suraski]

At 21:42 22-08-01, Chris Gardner wrote:
>i was noticing a slight problem with the whole EXT_SKEL shell script.  it
>works great for getting a new package up and running, but only if your'
>doing all your using basically the gcc compiler.  well, i've been trying to
>create an extension library for php, and i am mainly using visual c++ 6 sp 3
>on win2k.  i can run the EXT_SKEL in my cygwin prompt, and it makes the
>files, fixes the build scripts, and the configure options, etc.  but, it
>doesn't fix the win32 projects to add the new library.  has anyone else
>looked at this, or thied to look at this?
>
>if nobody else has burned this bridge before, let me know, i'll come up with
>something you guys can use.

I think the guys who worked on ext_skel were mostly UNIX oriented.  At any 
rate, no work has been done to automate Windows builds - so if you can 
contribute in this area, it would be cool!

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] object to string convertion patch

[Zeev Suraski]

At 20:08 22-08-01, Jeremy Bettis wrote:
>My implementation does not have these inconsistencies (I looked in the
>archives).  The only wierd thing is print_r and dump_var.

I think the inconsistency that was there was that my implementation was for 
displaying purposes only.  If you call to_string() in convert_to_string(), 
then it may be consistent (I'm not sure, I haven't thought about it 
thoroughly).  There was a reason on why we didn't switch to this as well, 
though.

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] object to string convertion patch

[Zeev Suraski]

At 19:53 22-08-01, Andrei Zmievski wrote:
>On Wed, 22 Aug 2001, Jeremy Bettis wrote:
> > I changed php (current CVS) to add another magic method to Objects,
> > __toString().  Whenever an object needs to be converted to a string, 
> then it
> > will first try to call __toString() and if it can't, then it will just
> > return "Object" like now.
>
>Good luck trying to get this in.

I implemented this once, and it was even in for several mini versions.  But 
it causes inconsistencies, and it was thus removed (I don't remember what 
the inconsistencies were, look up the archives...)

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] pif

[Zeev Suraski]

At 23:14 21-08-01, [EMAIL PROTECTED] wrote:
>What about using the pif_ prefix for php's internal functions, analogously
>to zif? This makes them more clear than the simple lack of PHP_API macro.

This sentence does not compute :)

Which functions are you talking about, and how does PHPAPI relate to them?

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 /ext/ircg README.txt

[Zeev Suraski]

At 23:44 20-08-01, Sascha Schumann wrote:
> >   I see no reason to put them in at the language level -- PEAR seems a
> >   suitable place for the extensions (once pear is setup).  They're not
>[..]
>
> I suggest postponing such a discussion until there are at
> least some signs of PEAR for C extensions on the horizon, or
> even better, until there is a working and functional
> mechanism for end-users.  Otherwise, it is just a waste of
> energy.

I agree!
Couldn't resist :)

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 /ext/ircg README.txt

[Zeev Suraski]

At 23:29 20-08-01, Sterling Hughes wrote:
> I see no reason to put them in at the language level -- PEAR seems a
> suitable place for the extensions (once pear is setup).  They're not
> really used that commonly (from what I can see).  Also, these
> extensions are not the only way to process payments with PHP, plenty
> of sites do it different ways (I processed payments with PHP before
> these extensions existed).

I think these discussions are kind of idle until the PEAR framework is ready.
The fact PHP comes with a rich variety of extensions is, in my opinion, one 
of the key reasons to its success.  It doesn't mean that this system cannot 
be redesigned in a way in which the extensions would ship separately, but 
we have to make sure it will not make installing extensions any more 
complicated or annoying than it is today.

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] Netscape cookies rather than RFC2109 or RFC2965?

[Zeev Suraski]

At 23:16 20-08-01, Rodent of Unusual Size wrote:
>Is there any particular reason why setcookie() uses the long-
>deprecated Netscape cookie syntax?

Downwards compatibility...

>   Would anyone object to
>my enhancing it to at least allow another argument specifying
>the syntax (Netscape Set-Cookie, RFC2109 Set-Cookie, or
>RFC2965 Set-Cookie2)?

I think that's fine, but it'll be coming after a long list of optional 
arguments :)

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 /ext/ircg README.txt

[Zeev Suraski]

At 23:04 20-08-01, John Donagher wrote:
>Processing payments on the internet is very special? No wonder so many
>businesses went under in the last few months.
>
>I think as long as PHP is a viable language for ecommerce development and
>hosting companies these extensions (Cybercash,pfpro,CCVS) make a lot of sense
>to have as part of the distribution. I'm not sure I've ever seen a clear
>argument as to why they don't.

Yep, I agree.

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] Chora and CVSWeb problems

[Zeev Suraski]

At 23:14 19-08-01, Rasmus Lerdorf wrote:
>That doesn't mean that the lack of proper mime type handling doesn't make
>it a useless browser.  People use all sorts of useless stuff every day.

As much as this is appetizing to start a nice browser war, I'll control 
myself.  I think an English teacher could argue with that last sentence of 
yours, though :)

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] Chora and CVSWeb problems

[Zeev Suraski]

At 22:31 19-08-01, Rasmus Lerdorf wrote:
> > Maybe Chora puts out an XML content type header, or
> > something, that makes IE think this is XML (as it
> > is not). I can't see the source, as IE just denies
> > to show the source in such cases saying "The XML
> > source file is unavailable for viwing). Please ask,
> > if more information is needed
>
>IE is a completely useless web browser.

That's why 75% of our users and like 90% of the Web uses it, eh? :)

>   It does not honour mime types and
>simply uses the file extension and/or any client-side file type
>associations.  Chora is doing the right thing.  On that com.xml URL you
>posted it is sending a text/plain Content-Type header.  The fact that IE
>choosed to pass text/plain to an internal XML parser is just one more
>reason you should never use IE for web browsing.  You never know what the
>thing is going to do.  I would not suggest changing Chora in any way with
>this respect.

'Hadin Yikov Et Hahar'.  I wish I knew how to translate that :)

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] Zend-Engine2

[Zeev Suraski]

At 19:48 19-08-01, Markus Fischer wrote:
>On Sun, Aug 19, 2001 at 07:40:06PM +0300, Zeev Suraski wrote :
> > At 19:37 19-08-01, Markus Fischer wrote:
> > >print_r( $a->b()->e()[0]);
> > >
> > >The last line gives parse error. So, I guess no yet supported?
> >
> > There are no plans to support this kind of dereferencing (arrays are still
> > native types).
>
>Oh ... sadly. I thought I read something about this in the draft.
>Then again, could be having to less sleep when reading it :|
>
>Is it like 'implementing this would be not trivial for the
>advantage gained' or is it like 'no one has yet considered about
>this syntax ?

The former more than the latter.  It also makes less conceptual sense.

Zeev


-- 
PHP Development Mailing List <http://www.php.net/>
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] Zend-Engine2

[Zeev Suraski]

At 19:37 19-08-01, Markus Fischer wrote:
> print_r( $a->b()->e()[0]);
>
>The last line gives parse error. So, I guess no yet supported?

There are no plans to support this kind of dereferencing (arrays are still 
native types).

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] about domxml api-change in 4.0.7

[Zeev Suraski]

At 00:54 19-08-01, Markus Fischer wrote:
>On Sat, Aug 18, 2001 at 11:07:08PM +0200, Jani Taskinen wrote :
> > Changes in experimental extensions don't require NEWS
> > entries. The NEWS file is already too hard to read.
> > With all those changes mentioned in it, it will become
> > totally useless.
>
>-1
>
>A news entry won't hurt that much it will probably aid ... wether
>EXP or not, domxml is stuff used by many people. We shouldn't be
>that strict just because its marked EXP after all..

I'm with Markus here...  It's quite easy to skip non interesting entries.

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-4.0.7RC1

[Zeev Suraski]

At 03:51 18-08-01, Richard Lynch wrote:
>Relying on initialization by the system instead of doing it by hand is bad.
>
>What if somebody then includes your file into something else, but has used
>that variable, but their final value is usually 0, except when it's not...
>
>Then, your code works for a while and then inexplicably breaks.
>
>Always initialize variables.

In that example, you would break the outer code if you initialize the 
variable...  The right solution here is separation using scopes (functions 
or classes).  I think that include()'ing logic into the global scope is not 
a very good idea unless they're integrated parts of the application.

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-4.0.7RC1

[Zeev Suraski]

At 19:54 17-08-01, Stanislav Malyshev wrote:
>I know. That's shaving with an axe - I can do it, but that's wrong thing
>to do. User should not be encouraged to fiddle with ini_set unless it is
>absolutely necessary.

I disagree.  ini_set() is kinda like inspector Gadget's hat, you can find a 
shaver there if you want to.
We can have a wrapper function, url_fopens_enable() which would in turn 
call ini_set(), but generally I think it's a bad idea to add these 
redundant functions.

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-4.0.7RC1

[Zeev Suraski]

At 19:35 17-08-01, Cynic wrote:
>This will happily run in E_ALL &~ E_NOTICE whether $x == 'foo' or not.
>Attacker can then inject $secure in the query string, and it'll apply
>whether or not $x == 'foo'. This will be caught with error_reporting
>E_ALL.

That's just a specific case of the register_globals problem.  We're already 
phasing register_globals out...  In the post register_globals era, the 
likelihood that E_NOTICE's will be hiding a security bug is much, much 
lower.  However, there are quite a few other situations in which E_NOTICE's 
are emitted, which are perfectly ok.  It has to do with coding style, not 
security.

>Yes, average PHP code is full of security or other holes.

E_NOTICE's only sometimes imply a security hole or a bug.  Very often, they 
imply absolutely nothing.

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-4.0.7RC1

[Zeev Suraski]

At 19:16 17-08-01, Stanislav Malyshev wrote:
>ZS>> I consider E_NOTICE as a basic element of good programming
>ZS>> practices.  Unlike register_globals, which simply begs for
>ZS>> security bugs to
>
>Actually, I fail to see why it is so. Let's see two code snippets:
>
>if($arr['foo']) { ... do something ... }
>if(isset($arr['foo']) && $arr['foo']!=false) { ... do something ... }
>
>Both have the same function, but the first generates E_NOTICE. Why the
>first is bad programming practice? How many PHP users would really prefer
>the second over the first?

This is one case in which there's no added value to E_NOTICE - in your 
example, you explicitly don't care whether the variable exists or 
not.  There are many cases in which there is an added value in 
E_NOTICE.  For example:

for ($i=0; $i<100; $i++) {
 $sum += sth()
}

print "The total some is $total";

True, a dumb programming error (it can get more complex), but an E_NOTICE 
would have caught in a second.  I think that in the post register_globals 
era it'll usually not help uncover security bugs, but it improves code 
cleanliness.

>ZS>> kind of suggestion.  That's why I think that adding it to the
>ZS>> php.ini-recommended is a good first step.
>
>However, it would make average PHP code to output tens of warnig, which
>would be annoying and would hardly be useful in many cases.

I agree.  I'm saying that it's a difficult call.

>ZS>> While we're at it, I think that we should also take another
>ZS>> recommendation from the advisory that brought this mess upon us
>ZS>> - and turn URL fopens off by default.
>
>Well, generally I personally would even go further and make two functions
>- one for file-only fopen (about 90% of fopen usage?) and another which
>would open everything and the kitchen://sink. Or make some switch, etc. -
>configuration option doesn't seem to me fit here, it's not per-server but
>per-script property if you want URL fopens or not.

You can set any INI entries using ini_set() for a particular script.  I 
think adding new functions is messy - too many functions in PHP support 
opening URLs (because they're built on top of fopen-wrappers).

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-4.0.7RC1

[Zeev Suraski]

At 17:43 17-08-01, Hellekin O. Wolf wrote:
>*** I understood that 4.0.7 / 4.1.0 would be a question of what we want next.

4.1.0 will.  We're not changing any defaults in 4.0.7...

>If E_ALL brings better code, why not encourage that ?
>Democracy is good as long as it's evolving. If we encourage a default lax 
>behavior, lax coders we'll have. If we encourage tighter programming, even 
>the novice can cope with it and learn faster, and make less mistakes, etc.
>Is that too optimistic ? Or am I forgetting the existing code base ?

I think it's a bit too optimistic, not to mention the existing code base :)

>I think that as $HTTP_*_VARS disappear, lots of people will have to change 
>that (Search/Replace + delete the corresponding "global" calls) anyway in 
>order to use the new $_* arrays in future versions.

There's a fundamental difference - setting E_NOTICE on means you have to 
audit *all* of your code, and in some cases, think about every possible 
execution path, just to see if you have a problem.  While the HTTP_*_VARS 
is an easy S&R issue, and even setting register_globals off affects only 
the form-interface part of the application and is usually also an issue of 
S&R (slower, but still S&R), there's no way to fix all notices in a quick 
way.  Even if you find the problems (which is very time consuming), fixing 
them can't be done using S&R, and it sometimes even requires changes to the 
logic.

It's not that "While we're at it" type of action, it has considerable 
additional implications.

>It's probably better to bother people once for good instead of once every 
>version. The purpose of 4.0.* vs .4.1.* should be clear for all : it's a 
>new step and you have to make it.

First off, nobody *has* to do anything.  They can always use an old 
version, or if we screw up too badly, switch to something else (I think the 
register_globals thing alone will take at least a year to catch, especially 
considering we're not eliminating the ability to turn it on).
We're walking on a fine line here, between keeping PHP's ease of use and 
cleanliness.  PHP is *definitely* not the cleanest language around, and 
it's not meant to be, either.  That's why not every action that would 
result in a 'cleaner' language is automatically applied.

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-4.0.7RC1

[Zeev Suraski]

At 17:43 17-08-01, Cynic wrote:
>This doesn't hold water. display_errors is on in php.ini-dist anyways,
>so what do you gain by display_startup_errors off?

Quite a lot.  Even if your code is rock solid, and has no warnings, errors, 
or notices whatsoever - or if you have error_reporting(0) at the top of it 
- it's still possible to make PHP emit startup errors at will.  That's 
exactly their meaning - errors that can occur due to a bogus request or 
during the request initialization, as opposed to a bug in the script.

>  NB you can use
>custom error handler that won't display full physical paths, so WTF?

Nope, you can't.  Startup errors occur before you can call custom handlers, 
before you can even declare them.  Beside, remember, you're talking about 
the default setting here.  Most people will never know what this option 
means, or what are its implications, or both, and definitely wouldn't be 
bothered to consider the ways to work around it :)

>BTW, what is the possibility of introducing new functionality to the
>default error handler, where the file paths aren't physical paths by
>default, but URIs? I. e. with DOCUMENT_ROOT in /var/www/, instead of
>"E_WARNING: blabla in /var/www/foo/bar.php on line xxx"
>display
>"E_WARNING: blabla in /foo/bar.php on line xxx"
>??

This should be done at the user level.  There's no reason to do it in the C 
level, which is much more complex.

>BTW, Zeev, could you please break your lines somewhere reasonable?
>It's quite unpleasant to read those loong lines. :) THX.

Hrm, which Email client today doesn't do word wrapping??

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-4.0.7RC1

[Zeev Suraski]

At 17:05 17-08-01, Cynic wrote:
>I'd do this:
>
>4.0.7:
>php.ini-standard   basically today's php.ini-dist
>php.ini-recommendedbasically today's php.ini-optimized
>+ the proposed security related changes
>what this is exactly I don't know. perhaps
>only register_globals off

This already exists today (except -standard is still called -dist, as 
there's no real reason to change it).  We may try to encourage people to 
read php.ini-recommended at the and of the build process, because I fear 
nobody's looking at it today.

>4.1.0:
>php.ini-standard   php.ini-recommended as contained in 4.0.7
>+ anything else you think should be there
>(it can be more "strict" than 4.0.7's rec.)
>php.ini-compat php.ini-standard as contained in 4.0.7

I'm not sure that we can just move to do -recommended version, 4.1.0 or 
not.  The nature of recommendations is that some people accept them, and 
some do not :)  None of the things in the php.ini-recommended file is a 
clear-cut must-have, and some people will prefer doing without them.  We'll 
have to think about each change separately.

Remember that we only use the version change to catch people's 
attention.  It doesn't mean that we can suddenly make PHP much more 
'hostile' :)

>And while I'm at it: can the Powers That Be consider switching the
>default setting for display_startup_errors to On in either of the
>ini files? I believe (my experience indicates it) that this would
>help to lower the confusion in some cases quite a bit: a message
>instead of just a 500 can change one's day.

There's a good reason for this default setting.  A clear message will not 
only change your day, but also the guy who's trying to hack your site's day 
:)  For example, with display_startup_errors set to on, a request can be 
easily made that will expose the full path of any scripts on your site.
It may make good sense to set it on in the -recommended version, as it's 
safe in conjunction with display_errors=0 and log_errors=1.

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-4.0.7RC1

[Zeev Suraski]

At 16:21 17-08-01, Cynic wrote:
>I vote for E_ALL as default in 4.1. NB I thought it was agreed
>that the same code will be released as 4.0.7 and 4.1.0 with the
>difference being php.ini settings. Was it a misperception on my
>part?

Defaults and ini settings (the binary will also reflect the new default 
php.ini settings).

The reasons I'm not sure about whether E_NOTICE should be in or not:

- The consequences of turning it on are extremely far reaching - it 
requires you to go over each and every line of your code, until the very 
last one, and check it, on the logical level (i.e., try to think about 
every possible path of execution).
- It's almost always harmless, especially after we change the default value 
of register_globals to off.

I'm very non decisive about my opinion on this one.  I know that in 1997 
when these warnings were added to the language in the first place, they 
were E_WARNING's.  Rasmus and others said that these warnings were too 
excessive, and introduced the NOTICE (or STRICT as it was called back then) 
error level, which was off by default, basically telling people it's ok to 
write code that way.  This happened about 4 years ago, at the early days of 
PHP 3.0.  Weighting the gain (it's there, but it's not overwhelming) and 
weighting the mess (it's there alright :), it very difficult to come up 
with a firm decision.

I consider E_NOTICE as a basic element of good programming 
practices.  Unlike register_globals, which simply begs for security bugs to 
occur, though, E_NOTICE is more of an application-level, code-cleanliness 
kind of suggestion.  That's why I think that adding it to the 
php.ini-recommended is a good first step.

While we're at it, I think that we should also take another recommendation 
from the advisory that brought this mess upon us - and turn URL fopens off 
by default.

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-4.0.7RC1

[Zeev Suraski]

At 12:00 17-08-01, Hellekin O. Wolf wrote:
>At 21:15 16/08/2001 +0300, Zeev Suraski wrote:
>>>What is the default error_reporting ? (When no value has been defined ?)
>>
>>The default error reporting is E_ALL & ~E_NOTICE - or, in other words, 
>>all types of errors and warnings, except for notices.
>>
>>Zeev
>
>*** Will that be a difference between 4.0.7 and 4.1 ? I mean, would 4.1 
>take E_ALL as a default ?

It hasn't been decided yet, but my guess is that it won't change.  It may 
be a good idea to add it into the php.ini-recommended, though.

Zeev


-- 
PHP Development Mailing List <http://www.php.net/>
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: Bug #12767 Updated: Apache compile with php4.0.6

[Zeev Suraski]

Can you try the latest CVS?

Zeev

At 21:22 16-08-01, Mike Hepworth wrote:
>The snapshot gives me the following error on the php make command:
>
>Making all in Zend
> /bin/sh ../libtool --silent --mode=compile cc -DHAVE_CONFIG_H
>-I. -I. -I
>../main   -I../TSRM  -g -prefer-non-pic -static -c
>zend_language_parser.c
> /bin/sh ../libtool --silent --mode=compile cc -DHAVE_CONFIG_H
>-I. -I. -I
>../main   -I../TSRM  -g -prefer-non-pic -static -c
>zend_language_scanner.c
>"zend_language_scanner.c", line 2697.7: 1506-282 (S) The type of the
>parameters
>must be specified in a prototype.
>make: The error code from the last command is 1.
>
>I tried both the latest version, and the second to latest version..
>
>Thanks,
>Mike Hepworth
>
>
>Stop.
>make: The error code from the last command is 1.
>
>
> >>> Bug Database <[EMAIL PROTECTED]> 08/15/01 10:28AM >>>
>ID: 12767
>Updated by: sniper
>Reported By: [EMAIL PROTECTED]
>Old Status: Open
>Status: Feedback
>Old Bug Type: *Compile Issues
>Bug Type: Compile Failure
>Operating System: AIX 4.3.3.0
>PHP Version: 4.0.6
>New Comment:
>
>Could you please try the latest CVS snapshot from
>
>http://snaps.php.net/ since this should have been
>
>fixed already.
>
>
>
>--Jani
>
>
>
>Previous Comments:
>
>
>[2001-08-15 11:12:56] [EMAIL PROTECTED]
>
>Whenever I try to compile Apache server 1.3.20 including the libphp4.a
>module, make crashes with a code 8.  It compiles just fine if I don't
>include the php directive.
>
>
>
>It is complaining about .alloc symbol.
>
>
>
>
>
>ATTENTION! Do NOT reply to this email!
>To reply, use the web interface found at
>http://bugs.php.net/?id=12767&edit=2
>
>
>--
>PHP Development Mailing List <http://www.php.net/>
>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 <http://www.php.net/>
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: Bug #12767 Updated: Apache compile with php4.0.6

[Zeev Suraski]

At 21:22 16-08-01, Mike Hepworth wrote:
>The snapshot gives me the following error on the php make command:
>
>Making all in Zend
> /bin/sh ../libtool --silent --mode=compile cc -DHAVE_CONFIG_H
>-I. -I. -I
>../main   -I../TSRM  -g -prefer-non-pic -static -c
>zend_language_parser.c
> /bin/sh ../libtool --silent --mode=compile cc -DHAVE_CONFIG_H
>-I. -I. -I
>../main   -I../TSRM  -g -prefer-non-pic -static -c
>zend_language_scanner.c
>"zend_language_scanner.c", line 2697.7: 1506-282 (S) The type of the
>parameters
>must be specified in a prototype.
>make: The error code from the last command is 1.

Ick.  What compiler is that?

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: Output Compression Issues

[Zeev Suraski]

At 21:27 16-08-01, Thies C. Arntzen wrote:
>On 16 Aug 2001 15:26:09 +0300, Zeev Suraski wrote:
> > - Output compression should probably check that the content type is 
> text/*,
> > and not perform compression otherwise
>
>that means adding another sapi call - but i think it would make sense.

Yep.

> > - We can look into sending the content length header from the output
> > compression callback
>
>if ithe output is not send as chunks we should do so - the original code
>for that (10 lines) was added by me and taken out by you a few days
>later when you added the chunking support.

Ah, good point.  That's exactly what I meant if somebody can think about 
good reasons not to do it :)

Chunking is quite important, and there's no way we can know in advance how 
many bytes we're going to end up having.  Unless we add in another output 
buffer.

Zeev


-- 
PHP Development Mailing List <http://www.php.net/>
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] [[PHP-DEV]

[Zeev Suraski]

At 20:01 16-08-01, Chris Gardner wrote:
>actually, i think both TYPE and LANGUAGE are required for validation
>purposes.  it really needs to support
>
>

Re: [PHP-DEV] Re: [PHP-QA] 4.0.7RC1 rolled

[Zeev Suraski]

www.php.net/~zeev/php-4.0.7RC1-Win32.zip

It only includes the CGI and ISAPI modules, and no additional extensions...



At 18:56 16-08-01, Harald Radi wrote:
>could you or someone else provide a windows binary of RC1.
>
>regards
>harald
>
>
>--
>PHP Development Mailing List <http://www.php.net/>
>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 <http://www.php.net/>
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: Output Compression Issues

[Zeev Suraski]

At 15:37 16-08-01, Troels Arvin wrote:
>On Thu, 16 Aug 2001 14:26:09 +0200, "Zeev Suraski" <[EMAIL PROTECTED]> wrote:
> > Can anybody think of good reasons not to send the content-length header
> > in case we're performing output buffering?

I meant "in case we're performing output compression" :I

>Personally: No.
>
>- However, the docs for the output handling system seems to indicate
>that output buffering "filters" may be nested. I could imagine that this
>will pose troubles if Content-Length headers are sent along in each
>output buffering module(?):
>http://www.php.net/manual/en/function.ob-start.php
>
>Quoting:
>
>  Output buffers are stackable, that is, you may call ob_start() while
>  another ob_start() is active. Just make sure that you call
>  ob_end_flush() the appropriate number of times. If multiple output
>  callback functions are active, output is being filtered sequentially
>  through each of them in nesting order.

Yeah, I know :)  However, the way it works, you're already pretty much 
screwed if you do anything with the compressed buffer anyway.

Zeev


-- 
PHP Development Mailing List <http://www.php.net/>
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: Output Compression Issues

[Zeev Suraski]

At 14:55 16-08-01, Troels Arvin wrote:
>On Thu, 16 Aug 2001 07:44:50 +0200, "John Donagher" <[EMAIL PROTECTED]>
>wrote:
>
> > So, we really want to disable output compression when we are serving
> > anything but HTML/text.
>
>I agree on that. I have heard that some older versions of both major
>browsers have trouble with compressed non-HTML content. - Or perhaps the
>ob_gzhandler could be given an argument telling it to be conservative or
>not?
>
>
>- Oh, and please:
>Could someone take a look at this bug which I really think is serious:
>http://www.php.net/bugs.php?id=12631
>
>As written, it's currently not possible to send proper Content-Length
>headers along with gz-encoded PHP-output because it's not possible to
>get the correct output-length information when using the gzhandler.
>
>When Content-Lengh headers are not sent, then Apache is not capable of
>using keep-alive == worse performance.
>
>There are lines like this in zlib.c:
>
>#if 0
> } else {
> char lenbuf[64];
>
> sprintf(lenbuf,"Content-Length: %d",Z_STRLEN_P(return_value));
> sapi_add_header(lenbuf,strlen(lenbuf), 1);
>#endif
>
>What does "#if 0" actually mean?
>
>If it's too hard to change the output buffering system to return proper
>content lengths, maybe it would be an idea to be able to tell
>ob_end_flush() that you want a Content-Length header to be sent along?
>(It seems that ob_gzhandler knows the correct Content-Length but is
>unable to pass that information along to the output buffering system.)

The output buffering system knows how many bytes were returned, but it 
doesn't really matter, as all it does with the returned bytes, is print 
them out (the output buffering system itself is not programmable).

So, to summarize:

- Output compression should probably check that the content type is text/*, 
and not perform compression otherwise
- We can look into sending the content length header from the output 
compression callback

Can anybody think of good reasons not to send the content-length header in 
case we're performing output buffering?

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] Please..

[Zeev Suraski]

At 13:39 16-08-01, Sascha Schumann wrote:
> >  From the annotated license:
> > "Any technique is acceptable for keeping changes separate - generally, you
> > would have to mark changes very clearly for them to be separate. We don't
> > want to hard-code the idea that the form must be patches. "
>
> And that is exactly what they did.  They explicitly suggest
> using patches.  You are not safe to use anything else,
> because the interpretation of 'separateness' can differ
> from court to court.  While courts usually listen to a
> license author's interpretation, the wording here needs
> improvements in order to meet the meaning of the "Annotated
> License..As Applied To The Qt Free Edition Version 2.0".

Could be.  Chances are that with the company who wrote the license 
explaining what it meant the way it did, it'll be an uphill battle to fight 
against it.

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] 4.0.7RC1 rolled

[Zeev Suraski]

You're building Release_TSDbg, right?
Something's broken with this build.  Try Release_TS or Debug_TS.  I'll try 
to figure out what's wrong with Release_TSDbg.

Zeev

At 13:52 16-08-01, Phil Driscoll wrote:
>Just tried to build on Windows but got the following warning & error.
>
>E:\F\php\php-4.0.7RC1\php-4.0.7RC1\ext\calendar\jewish.c(270) : warning
>C4005: 'SDN_OFFSET' : macro redefinition
> E:\F\php\php-4.0.7RC1\php-4.0.7RC1\ext\calendar\gregor.c(0) : see
>previous definition of 'SDN_OFFSET'
>
>...
>
>Creating library cyr_convert.lib and object cyr_convert.exp
>LINK : fatal error LNK1561: entry point must be defined
>Error executing cl.exe.
>
>php.exe - 1 error(s), 36 warning(s)
>
>--
>Phil Driscoll

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


-- 
PHP Development Mailing List <http://www.php.net/>
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] Please..

[Zeev Suraski]

At 13:19 16-08-01, Sascha Schumann wrote:
> > Having now re-read the Q license a few times, the PHP license a few
> > times, this seems unrelated to licensing, and more related to
>
> You might want to reread the QPL then.  The important point
> is clause 3 which prohibits distributing changes, unless they
> are provided as patches.  This is highly unpractical, because
> it even does not permit you to run a CVS server where
> something simple as browsing the CVS using Chora or doing a
> checkout would already constitute distributing the changes.
> So, any source-code which is under the QPL will hardly
> become a source for further external development, because the
> changes are unmaintainable.

 From the annotated license:
"Any technique is acceptable for keeping changes separate - generally, you 
would have to mark changes very clearly for them to be separate. We don't 
want to hard-code the idea that the form must be patches. "

http://www.trolltech.com/products/download/freelicense/annotated.html

(this is not an encouragement to make you fork, just pointing out that 
you're wrong).

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] Linux Today Article

[Zeev Suraski]

I don't usually buy into long term visions, because they virtually never 
work.  Microsoft changed its vision twice in the last 5 years, 
*completely*, from end to end.  Sun (and the other Java followers) have 
also changed their Java vision several times during its short lifespan, 
also, from end to end.  In reality, where a language goes is strongly 
decided by the userbase, and not by the vendors.  In the .NET case it might 
work, because Microsoft is one of the only companies that actually stand a 
chance at imposing their will on the market, if what they offer is 
reasonably good (which .NET is, apparently).

Giving it a try doesn't hurt, though.  I just explained why I liked Blake's 
non politically correct statement :)

Zeev

At 10:58 16-08-01, Kristian Koehntopp wrote:
>On Thu, Aug 16, 2001 at 02:24:27AM +0300, Zeev Suraski wrote:
> > >I've rambled a bit, but my feeling is that the Linux Today Article is
> > >premature.  PHP can (and likely will) support the features mentioned 
> in the
> > >article, but the real question is, are these really the features that are
> > >going to be used?
>
> > Very nice non-PC statement! :)
>
>A programming language is not only a tool and a framework, it
>also is a set of people sharing a common vision and working
>together - a community. What Microsoft provided with .net
>is not so much a product - yet. It is a vision, though, and
>a plan where they want to go in the next few years.
>
>So to compete here, PHP need not only be superior in technical
>checklist items, it also has to provide a kind of development
>roadmap, a plan where it wants to be in 3 and in 5 years, and
>what services it will provide to developers then. That is the
>PHP vision that the language and the system needs to stand the
>marketing onslaught by Microsoft.
>
>Note how other communities, notably Perl, provided such a vision
>in the past (e.g. the mythical Perl compiler), and continue
>to provide such visions now (e.g. Perl 6 and flexible scanners
>to turn Perl into the one language to parse all syntaxes). Larry
>provides even more - with his speeches and interviews he even
>provides a kind of philosophy behind Perl, a greater concept
>to explain not only how, but also why things have been done the
>way they have been done.
>
>As you can see in the case of Perl, the vision need not be
>final, useful or even true, it just needs to be cool, and
>believable. It is being used as a tool to bind the community
>tigther together, to provide hope and a sense of direction.
>
>
>To come back to PHP: What is the place of PHP in 3 and in 5
>years, what are the next big projects tackled in the
>development of PHP, and what is the larger idea behind PHP -
>what does the language _want_ to become, and what audience will
>it cater. If you can answer these questions for your developing
>audience, these answers will have a large influence on the
>qualification and quantity of audience you have.
>
>PHP 2005 - If you code it, they will come.
>
>Kristian
>
>--
>Kristian Köhntopp, NetUSE AG Dr.-Hell-Straße, D-24107 Kiel
>Tel: +49 431 386 435 00, Fax: +49 431 386 435 99

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


--
PHP Development Mailing List <http://www.php.net/>
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] Please..

[Zeev Suraski]

As you know, most of your questions were hypothetical.  I tried to answer 
them and take them seriously, even if they weren't very likely or serious :)

At 11:05 16-08-01, Ron Chmara wrote:
>1. If the relationship between Zend Tech and PHP becomes irreconcilable,
>can PHP and Zend fork and/or recover in some other means?

Yes.

>2. If all of the current PHP and Zend core developers die in a fire at
>a convention, can the codebase continue, or will the ZE possibly become the
>property of somebody who could demand $1,500 (USD) per server for licensing,
>and lock down the source, thus killing PHP and Zend?

No.

>3. Is the Zend license preventing useful submissions from people who
>write damn good code, but are FSF believers/zealots, so they refuse to
>contribute, because it doesn't have the RMS seal of approval?

Yes.  So does the PHP license, though, and many other licenses, like the 
ASF license.

>4. If an alternate engine was written, would it be possible to use
>with PHP? Could an engine be written from Zend code, or would it
>have to be clean-room code, and if so, from what version of PHP?

Obviously, other engines can be written.  I was involved in writing two 
such engines in the past.  Because parts in PHP are very tightly coupled 
with the engine infrastructure, it would have to be very similar to the 
existing engine, to a degree that makes it kind-of dumb to do in the first 
place.
I'm not a lawyer, but I guess that if you were to call it your own, and 
release it under a different license, you would have to write it from scratch.

>5. If, say, Microsoft beats Zeev and Andi in a Redmond basement for
>three weeks, until they sign away all rights with bloody, mangled
>hands, can PHP go forward, or does it have to back up? (See the
>tim robbins "antitrust" movie... he becomes a software giant through
>artful purchasing, and the occasional assasination...)

They tried to, but we fought back bravely ;)
What you make of this question depends on what you think our contribution 
is to the project.  From a legal standpoint, it can go on just fine, we 
just won't be in the work force.

>6. If a core member goes insane, can they damage PHP without
>being held in check somehow? If half the core dies, is it distributed
>enough that the other half can continue?

Being a member of the PHP Group doesn't buy you too much nowadays.

>Core to the license debate:
>7. Can the Q license currently used be adapted to meet the needs/fears
>of GPL/BSD and similar folks, without compromising the Zend Tech needs
>for having a saleable product? (there's quite a few licenses out there...)
>from what I understand, Stallman's complaint are the credits clauses,
>others are worried about selling closed source (ironically, isn't a
>Zend package designed specifically for this pupose?)

I *really* don't care about Stallman specifically, or about GPL 
compatibility.  I'm a strong supporter of the BSD style license, and if the 
Zend Engine license changes, chances are it will be to a BSD license, like 
PHP's.

>Core to the debate debate:
>8. Do some people just need to shoot off some steam, and accomodate
>others who do? I get 1000+ emails a day, this is nothing in comparison.
>Of course, I also go days without reading certain lists, which helps.
>:-)

I'll leave that one to somebody else :)

>Rasmus, Zeev and Andi are not eternal, neither is PHP or Zend. Planning
>now, however, makes the future easier. Some folks live in volatile parts
>of the world about to go to war, :-) , some do not. Some take "breathers"
>when they are angered, some do not. So I'm interested in how PHP survives
>everything from worst case to best case... it seems bulletproof, in code
>terms, because the Q license allows at least one form of forking, if not
>several.

Right.

>Having now re-read the Q license a few times, the PHP license a few
>times, this seems unrelated to licensing, and more related to
>"mindshare" or the power fluctuations of a given group, or
>reactionary impulse to Zend being part commercial, part free. Even
>in worst case, PHP could recover in months to a year or so, with the
>hardest part being the social damage of bitter debate, or a focus
>entirely on an engine rewrite.
>
>I dunno. ANy lawyers on the list?

At least you read it and tried to understood it, which is more than what 
the average person does...

>Anyways, I'm off to go play in the SF bay now. Have fun, folks!

Have fun,

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] Linux Today Article

[Zeev Suraski]

Very nice non-PC statement! :)

Zeev

At 02:20 16-08-01, Blake Schwendiman wrote:
>Just my opinion, but right now (meaning this year, maybe a little longer) I
>feel that PHP is more than adequate for developing small, medium and large
>sites.  I work on both sides of the fence.  My day job has been developing
>portions of large web sites using ASP/COM/COM+ and the evolution of these
>tools which is the frame of the .NET product/service.  For my personal and
>more interesting work, I prefer PHP by far.
>
>I feel that there is a mass of hype surrounding new development paradigms,
>but we are far from declaring one technology a winner.  ASP is provided by a
>company with a great deal of resources and an interest in providing tools to
>its customers.  I don't have a problem with that, but right now I don't
>think many of the customers really know what they want.  With no offense
>intended toward many working hard on and with XML, I say XML hasn't proved
>its worth in very many places.  I personally don't know anyone who is using
>XML for anything and very few who have plans to use it.  So why should I get
>worried about whether a language currently supports one of its extensions.
>Am I using it?  Are my customers using it?  Really?
>
>The ASP model has some wonderful features.  Components can be great, but too
>much componentization can be a nightmare.  In my personal experience an
>enterprise component architecture is a double-edged sword.  It's great to be
>able to plug in well-built components and use them, but the downside is that
>component writers disappear, companies go out of business, support can be
>difficult to obtain and so on.
>
>I've rambled a bit, but my feeling is that the Linux Today Article is
>premature.  PHP can (and likely will) support the features mentioned in the
>article, but the real question is, are these really the features that are
>going to be used?  Will I be developing web applications with these features
>in 1 year, 3 years or 5 five years?  Is PHP or ASP (.NET) providing me with
>the real tools I need to develop web applications today?  For me, both tools
>provide what I need today, but I like PHP better.
>
>Blake
>
>-Original Message-
>From: Sebastian Bergmann [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, August 15, 2001 2:30 PM
>To: php-dev mailinglist
>Subject: Re: [PHP-DEV] Linux Today Article
>
>
>Edin Kadribasic wrote:
> > Where is the PHP enterprise component architecture?
>
>   What exactly would that be?
>
> > What about clustering and failover?
>
>   This has nothing to do with the language, IMHO, but with the
>   platform, ie. the web server. I guess there are solutions to
>   provide clustering and fail-over to Apache and MySQL, for
>   instance.
>
> > Where are the WSDL and UDDI implementations?
>
>   What are WSDL and UDDI? Are there libraries out there can be
>   wrapped into an extension?
>
> > Show me a framework.
>
>   Horde is a framework, and I guess there are some more out there.
>
>   But I fear that there is truth in this. We should analyze what,
>   besides the upcoming changes on the language level (with the
>   Zend Engine 2.0), we need to make PHP compatible with ASP.NET.
>
>   Maybe Zend has some feedback from their enterprise clients on
>   what features are requested, etc.
>
>--
>   Sebastian Bergmann Measure Traffic & Usability
>   http://sebastian-bergmann.de/http://phpOpenTracker.de/
>
>--
>PHP Development Mailing List <http://www.php.net/>
>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 <http://www.php.net/>
>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 <http://www.php.net/>
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] basic_functions.c broken

[Zeev Suraski]

Fixed.

At 01:35 16-08-01, Alexander Wirtz wrote:
>Hi folks,
>
> >basic_functions.c
> >D:\home\php\php4\ext\standard\basic_functions.c(306) : error C2065:
> >'zif_exp2' :
> > nichtdeklarierter Bezeichner
> >D:\home\php\php4\ext\standard\basic_functions.c(306) : error C2099:
> >Initialisier
> >ung ist keine Konstante
> >D:\home\php\php4\ext\standard\basic_functions.c(307) : error C2065:
> >'zif_exp10'
> >: nichtdeklarierter Bezeichner
> >D:\home\php\php4\ext\standard\basic_functions.c(307) : error C2099:
> >Initialisier
> >ung ist keine Konstante
> >D:\home\php\php4\ext\standard\basic_functions.c(308) : error C2065:
> >'zif_log2' :
> > nichtdeklarierter Bezeichner
> >D:\home\php\php4\ext\standard\basic_functions.c(308) : error C2099:
> >Initialisier
> >ung ist keine Konstante
>
>I can confirm this on my linux-box:
>
>basic_functions.c:306: `zif_exp2' undeclared here (not in a function)
>basic_functions.c:306: initializer element for 
>`basic_functions[157].handler' is not constant
>basic_functions.c:307: `zif_exp10' undeclared here (not in a function)
>basic_functions.c:307: initializer element for 
>`basic_functions[158].handler' is not constant
>basic_functions.c:308: `zif_log2' undeclared here (not in a function)
>basic_functions.c:308: initializer element for 
>`basic_functions[159].handler' is not constant
>basic_functions.c:310: `zif_cbrt' undeclared here (not in a function)
>basic_functions.c:310: initializer element for 
>`basic_functions[160].handler' is not constant
>make[3]: *** [basic_functions.lo] Error 1
>make[3]: Leaving directory /data/www/php4/ext/standard'
>
>
>Regards
>Alex
>
>--
>| Alexander Wirtz   | eMail: [EMAIL PROTECTED]|
>| web@ctive GmbH    | WWW:   http://www.web-active.com   |
>
>--
>PHP Development Mailing List <http://www.php.net/>
>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 <http://www.php.net/>
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] Setting up RFC

[Zeev Suraski]

At 21:24 15-08-01, Sterling Hughes wrote:
> Oh - I see! So the "Zend" on the License is really just shorthand for
> "Zeev and Andi", has nothing to do with Zend Technologies Ltd.  Good
> to know. ;))

In practice, pretty much, yes.  I don't remember Doron's, Adi's or Daniel's 
last contributions :)

> As I said -- this may have no basis in practicality -- I think it
> does to some extent, otherwise you wouldn't hear this many
> reasonable (but sometimes passionate) people complaining.  Still,
> taking your assumption that the license and Zend's control of it is
> meaningless, why not go ahead and change the license today?  If it
> means nothing, why are you with a license that causes such strife in
> the PHP community?

A small part in the PHP developer community, mind you.  As I told Stig, it 
is what you make of it - practically, it's nothing.

>   If you'd like, I'll go setup a sourceforge project for
> the Zend engine today!

I don't want to see the engine as a sourceforge project today, tomorrow, or 
anytime in the future, thank you very much :)

As I said in LinuxTag, the license issue was blown out of proportion 
completely.  It has no practical meaning for any PHP user or 
developer.  Changing the license only means that we will no longer be able 
to re-license the engine to other companies who make commercial use of 
it.  So basically, changing it means a loss of a source of possible income 
for Zend, while giving the PHP community nothing (MySQL AB *lives* from 
that source of income exactly).  Perception wise, it might make the world 
much more rosy.  To be bluntly honest, I seriously doubt it (we're not in a 
bad shape today, plus I have every reason to believe that things won't 
change radically if&when we change the license).  As far as Zend is 
perceived, much like the license issue was a non issue until some made it 
an issue, I fear that once it's gone, there'll be something else to replace 
it.  When you don't like somebody or something, you can find whatever suite 
of 'objective' reasons to back you up.

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] 4.0.7RC1 rolled

[Zeev Suraski]

Done!

At 21:32 15-08-01, Jani Taskinen wrote:

>Could you add a symbolic link for it:
>
>php-4.0.7RC-latest.tar.gz
>
>And keep that linked to the latest.
>
>--Jani
>
>
>On Wed, 15 Aug 2001, Zeev Suraski wrote:
>
> >http://www.php.net/~zeev/php-4.0.7RC1.tar.gz (not mirrored)
> >
> >
> >

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


-- 
PHP Development Mailing List <http://www.php.net/>
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] SAPI_API glitch

[Zeev Suraski]

At 20:35 15-08-01, Daniel Beulshausen wrote:
>isn't that exactly what i meant in my first mail? :)

I'm thick ;)

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] 4.0.7RC1 rolled

[Zeev Suraski]

http://www.php.net/~zeev/php-4.0.7RC1.tar.gz (not mirrored)


-- 
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] SAPI_API glitch

[Zeev Suraski]

At 20:20 15-08-01, Daniel Beulshausen wrote:
>At 19:33 15.08.2001 +0300, Zeev Suraski wrote:
>>At 18:40 15-08-01, Daniel Beulshausen wrote:
>>>At 17:36 15.08.2001 +0200, Daniel Beulshausen wrote:
>>>>At 18:20 15.08.2001 +0300, Zeev Suraski wrote:
>>>>>Is there any reason to have them even exported?  I think we can just 
>>>>>nuke SAPI_API altogether (I could be wrong, we might be referencing 
>>>>>them somewhere, but I don't think we do)
>>>>
>>>>not sure, but we can add it later if it breaks :)
>>>
>>>no i just looked, they are (i.e. sapi_read_standard_form_data in the fdf 
>>>extension)
>>
>>They are what? :)
>
>breaking && using exported SAPI_POST_* functions.
>i conclude, they still should get exported. :)

Why?  Are modules using any SAPI_POST functions which are defined in 
PHP?  If they are, we should probably change the SAPI_POST_HANDLER 
definition not to include SAPI_API, and add the SAPI_API explicitly before 
those functions which are referenced by modules.

Zeev


-- 
PHP Development Mailing List <http://www.php.net/>
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] SAPI_API glitch

[Zeev Suraski]

At 18:40 15-08-01, Daniel Beulshausen wrote:
>At 17:36 15.08.2001 +0200, Daniel Beulshausen wrote:
>>At 18:20 15.08.2001 +0300, Zeev Suraski wrote:
>>>Is there any reason to have them even exported?  I think we can just 
>>>nuke SAPI_API altogether (I could be wrong, we might be referencing them 
>>>somewhere, but I don't think we do)
>>
>>not sure, but we can add it later if it breaks :)
>
>no i just looked, they are (i.e. sapi_read_standard_form_data in the fdf 
>extension)

They are what? :)

Zeev


-- 
PHP Development Mailing List <http://www.php.net/>
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] SAPI_API glitch

[Zeev Suraski]

Is there any reason to have them even exported?  I think we can just nuke 
SAPI_API altogether (I could be wrong, we might be referencing them 
somewhere, but I don't think we do)

At 17:58 15-08-01, Daniel Beulshausen wrote:
>hi
>
>currently if extensions want to define their own SAPI_POST_*_FUNC (fdf, 
>mbstring) they'll run into trouble, because they are defined as 'SAPI_API 
>void ... my_handler'. this however doesn't work, because you'll need to 
>define SAPI_EXPORTS (to export it) and are thus loosing the 
>sapi_globals_id (which must be imported).
>nuking SAPI_API from the macro, and using (SAPI_API || PHP_EXT_API) 
>SAPI_POST_*_FUNC would avoid this glitch.
>anyone objects?
>
>daniel
>
>/*--
>daniel beulshausen - [EMAIL PROTECTED]
>using php on windows? http://www.php4win.de
>
>
>--
>PHP Development Mailing List <http://www.php.net/>
>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 <http://www.php.net/>
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] Setting up RFC

[Zeev Suraski]

At 18:13 15-08-01, Andrei Zmievski wrote:
>On Wed, 15 Aug 2001, Zeev Suraski wrote:
> > like.  That's why the situation wouldn't change radically if/when the
> > engine license changes, much like it wasn't any different *before* the
> > engine license was even introduced, in the PHP 3.0 days.  Having 
> regulators
> > over the 'kernel' of the project is certainly not very unique to the PHP,
> > and had a significant role in bringing PHP to where it is today, and not
> > where Perl is today, for example.
>
>You always compare PHP to Perl. How about Python? It's a well designed
>language that's pretty open for development.. Look at their PEPs system.

And you always compare to Python :)  I try to compare apples and apples.  I 
don't see Python as an equivalent of PHP, whereas I do see Perl as 
something that had to potential to be a good thing, and blew it.  There are 
also many other, non-language examples, of opensource projects that work in 
the same way.

Zeev


-- 
PHP Development Mailing List <http://www.php.net/>
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] Please..

[Zeev Suraski]

At 13:53 15-08-01, David Hjortsoe wrote:
>For me this means that no matter what happens to Zend, the PHP Group
>can, if it wishes to do so, continue to develop the ZE without any
>restrictions except to keep the ZE under the license that it is
>currently under, am I missing something?

The only thing you're missing is the point of these threads.  They have 
very little to do with the situation itself, and everything to do with 
politics.  If, God forbid, you only look at the facts - then you're not 
missing anything.

Thanks for providing a rational look!

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] Please..

[Zeev Suraski]

At 13:41 15-08-01, Sascha Schumann wrote:
> > If you feel like bickering, go on bicker and make populist statements as
> > much as you'd like, just let the rest of us do what we're good at, which is
> > developing PHP.  Perhaps setting up a separate mailing list like Sterling
> > suggested, a-la [EMAIL PROTECTED] isn't such a bad idea.
>
> Thanks for proving that you are not interested in a dialogue.

If bickering is your definition of dialogue then all I can say is - you're 
quite welcome!

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] Please..

[Zeev Suraski]

At 13:43 15-08-01, Sebastian Bergmann wrote:
>Jani Taskinen wrote:
> > Can you guys give up these childish fights and just code?
>
>   These are not childish fights.

Yes they are.  They are on childish topics, lead nowhere and consume lots 
of our time.

>  And I assume there are some people
>   out there, just like Sascha and Thies, who are waiting to code
>   and contribute the Zend Engine, once the license gets changed.

You have absolutely no reason to assume that this is the case, except for 
the license noise that was spawned by the same people who spawn these 
pointless threads on php-dev.  I believe Hartmut will help documenting the 
API, but that's about it.

>   But chaning the license is only one step that Andi and Zeev need
>   to take, IMHO.
>
>   A second one would be documenting the Zend Engine's internals.
>   And this can only be done properly by Andi and Zeev, since they
>   planned and coded it.
>   Looking at zend_compile.c and zend_execute.c today just gives me
>   the creeps, from a software developer's view: nearly no
>   comments.
>   Of course, I can guess what is done where, since I know a bit on
>   compiler theory. But with a proper documentation, people like
>   Sascha and Thies could start with their work on the engine right
>   away -- without learning (by guessing) how the Zend Engine
>   actually does what it does.
>
>   While the Zend API could easily be documented, or updated from
>   what's in ZendAPI on cvs.zend.com, from any developer who wrote
>   some PHP extensions, the documentation of the Zend Engine itself
>   and its internals can IMHO only be done by its creators.

With all due respect, 'you get what you pay for' works as far as 
documentation goes in open source.  Fact is, we don't *need* to do 
*anything*.  Nobody in an opensource project does.  What we do we do 
because it's fun (which these threads do a good job of ruining) and because 
it's interesting.  Not because we have to do it.
I never liked writing documentation.  I don't think that developers in most 
other opensource projects are significantly different, neither are most of 
the other developers in the PHP circle (it's not as if the rest of PHP is 
too documented...  Where are the SAPI docs, or the fopen wrappers docs, or 
the session docs?).  Try to understand the Perl source code, for 
example.  For me, things work just fine the way they are, and I'm not 
searching for extra stuff to do.  If somebody finds the entry level too 
steep to contribute to the engine, by all means, either try to document it, 
or go away.  Don't say that I *have* to do it, because I don't.

Sorry for the somewhat aggressive tone, but it's kind of annoying to see 
people demanding things from you, when you're a volunteer.

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] Please..

[Zeev Suraski]

At 13:13 15-08-01, Sascha Schumann wrote:
>On Wed, 15 Aug 2001, Jani Taskinen wrote:
>
> >
> > Can you guys give up these childish fights and just code?
>
> Telling people to just shut up will not resolve the issues
> which many of us think have to be addressed (regardless of
> how profane your language becomes).  It is very unlikely that
> the bickering will stop, if a single company continues to
> exercise so much control over the future of an open system
> such as PHP.

If you feel like bickering, go on bicker and make populist statements as 
much as you'd like, just let the rest of us do what we're good at, which is 
developing PHP.  Perhaps setting up a separate mailing list like Sterling 
suggested, a-la [EMAIL PROTECTED] isn't such a bad idea.

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] Please..

[Zeev Suraski]

At 13:06 15-08-01, Jani Taskinen wrote:
>p.s. Zeev, did you forget to tag the Zend / TSRM for 4.0.7 ??

Nah, I even did that last night at 2am...  But I got a bug report in the 
CGI that required fixing, and there's some COM patch that should go in 
before RC1, so RC1 will be delayed in a few hours...

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] Setting up RFC

[Zeev Suraski]

At 12:15 15-08-01, Sterling Hughes wrote:
>On Wed, 15 Aug 2001, Zeev Suraski wrote:
>
> > At 10:23 15-08-01, Stig Sæther Bakken wrote:
> > >[Hi,
> > >
> > >I think one of the problems with this is that even if php-dev comes up
> > >with a system for determining which feature it wants to see in PHP, we
> > >still depend on Zeev, Andi or someone else @ Zend to implement them.
> > >An RFC system would be a support for Zend's decision-making.  At the
> > >end of the day, due to the licensing issues, php-dev is not the body
> > >governing the language, it has an advisory role only.
> >
> > Generally, I agree with you, except it's not because of licensing issues
> > (will we end up with a load of features suddenly getting into PHP if/when
> > the engine license changes?).  Many other projects behave that way.  With a
> > language definition, "vox populi, vox Dei" doesn't tend to work very well.
> >
>
> Yes, the difference is, this creates a situation where the PHP 
> Development
> team does not have control of the core language, Zend Technologies Ltd.
> does.  Whether this is a issue with a basis in principle or a basis in
> practicality is up to debate, however, the problem remains.

Sterling, that's bull - popular perhaps - but still, bull.  Zend as a 
commercial entity doesn't decide on PHP's features.  Nobody in Zend has 
control over the language just because he's a Zend employee.  Other Zend 
employees participate in the discussions just like the rest of you, and 
often make quite constructive remarks, just like the rest.  However, it's 
not as if Zend employees can muck around the language, whereas php-dev can 
just stand on the side watching.
We all like to look up at corporations, blame them for the problems and 
rebel.  It's basic human nature.  It just has very little to do with 
reality in this case.  Nothing, in practice, except for that license 
everybody enjoys bashing (and I claim again and again, that it won't make a 
radical change if it changes, except for perception).
Andi and myself regulate the engine, on a personal basis, since 1997, and 
it has nothing to do with Zend (which was founded towards the end of 
1999).  Between us, as a commercial entity, nobody could care less whether 
there are advices, namespaces or how exactly the object model would look 
like.  That's why the situation wouldn't change radically if/when the 
engine license changes, much like it wasn't any different *before* the 
engine license was even introduced, in the PHP 3.0 days.  Having regulators 
over the 'kernel' of the project is certainly not very unique to the PHP, 
and had a significant role in bringing PHP to where it is today, and not 
where Perl is today, for example.

Zeev


--
PHP Development Mailing List <http://www.php.net/>
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] Setting up RFC

[Zeev Suraski]

At 10:23 15-08-01, Stig Sæther Bakken wrote:
>[Hi,
>
>I think one of the problems with this is that even if php-dev comes up
>with a system for determining which feature it wants to see in PHP, we
>still depend on Zeev, Andi or someone else @ Zend to implement them.
>An RFC system would be a support for Zend's decision-making.  At the
>end of the day, due to the licensing issues, php-dev is not the body
>governing the language, it has an advisory role only.

Generally, I agree with you, except it's not because of licensing issues 
(will we end up with a load of features suddenly getting into PHP if/when 
the engine license changes?).  Many other projects behave that way.  With a 
language definition, "vox populi, vox Dei" doesn't tend to work very well.

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] Branching 4.0.7RC1 today

[Zeev Suraski]

Just a reminder - I plan on branching 4.0.7 today as planned, in a few hours.

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] Bug #12721: PHP crashes at any code-highlight related command

[Zeev Suraski]

At 20:07 13-08-01, [EMAIL PROTECTED] wrote:
>From: [EMAIL PROTECTED]
>Operating system: Redhat/7.0, kernel 2.2.16
>PHP version:  4.0.6
>PHP Bug Type: Reproducible crash
>Bug description:  PHP crashes at any code-highlight related command
>
>I have (over several versions of apache and php) noticed a very strange
>bug: PHP keeps crashing the Apache when using .phps files or any of the
>highlight_*() family (including show_source, of course).
>
>The child dies with SIG11, gdb output follows:
>
>-- SNIP --
>Core was generated by `/usr/local/apache/bin/httpd'.
>Program terminated with signal 11, Segmentation fault.
>#0  0x400097fd in ?? ()
>(gdb) bt
>#0  0x400097fd in ?? ()
>#1  0x4000cea0 in ?? ()
>#2  0x4000d020 in ?? ()
>#3  0x8061793 in php_fopen_primary_script ()
>#4  0x400cfbfc in ?? ()
>-- SNAP --
>
>phpinfo() is at http://www.de-punkt.de/info.php
>
>There have been *no* similar issues on this machine (i.e. a build of mysql,
>which should evoke generic memory or CPU issues as well, runs through
>pretty clean), it only keeps crashing with PHP (and the Zend Cache, that is
>;-) ).

Does it crash every time - will a simple highlight_string("hello"); crash it?

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] associative arrays

[Zeev Suraski]

At 12:47 13-08-01, Markus Fischer wrote:
>I was just kidding, really.

You sure have fooled me ;)

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] associative arrays

[Zeev Suraski]

Actually, this is quite well documented, if you actually try to look the 
documentation up...

http://www.zend.com/apidoc/x1243.php

Zeev

At 12:24 13-08-01, Markus Fischer wrote:
>go Rasmus go! :-)
>
>Some more examples and we seriously can extend zend.com/apidoc .
>
>Such examples are of great value to anyone who is new to writing php
>extension.
>
>- Markus
>
>On Mon, Aug 13, 2001 at 02:14:01AM -0700, Rasmus Lerdorf wrote :
> > Ah, ok.  It's not much harder:
> >
> >   pval *tmp_arr;
> >
> >   array_init(return_value);
> >   MAKE_STD_ZVAL(tmp_arr);
> >   array_init(tmp_arr);
> >   add_assoc_string(tmp_arr, "string index", "foo", 1);
> >   zend_hash_index_update(Z_ARRVAL_P(return_value), 5, &tmp_arr, 
> sizeof(tmp_arr), NULL);
> >
> > This will create  $whatever[5]['string index'] = 'foo'
> >
> > Or if you want a string index at the top level:
> >
> >   zend_hash_update(Z_ARRVAL_P(return_value), "bar", strlen("bar")+1, 
> &tmp_arr, sizeof(tmp_arr), NULL);
> >
> > This will create  $whatever['bar']['string index'] = 'foo';
> >
> > -Rasmus
> >
> > On Mon, 13 Aug 2001, Thomas Wentzel wrote:
> >
> > > Uhhh sorry!
> > >
> > > What I should have said is that... The associative array I wish to
> > > return is to be an array element of  an associative array ;)
> > > Meaning... I need the functionality of add_assoc_array but since
> > > this function doesn't exist - I have to manipulate with the
> > > zend_hash_xxx in order to get what I want - but I fail to connect
> > > my constructed array with a name...
> > >
> > > Rasmus Lerdorf wrote:
> > > >
> > > > > I was wondering if someone would be so nice as to post a code
> > > > > snippet that returns an associative array... I'm writing an
> > > > > extension and am only able to return an ordinary array...
> > > > > Alternatively I would be very interested if someone could
> > > > > point me to some documentation on the zend_hash_xxx functions
> > > >
> > > > array_init(return_value);
> > > > add_assoc_string(return_value, "string index", your_char_var, 1);
> > > > add_assoc_double(return_value, "another one", your_long_var);
> > > >
> > > > That's all.  Last arg on add_assoc_string() should be 1 if you need to
> > > > make a copy of the string.  If the char * you are passing was 
> allocated by
> > > > you using emalloc() then don't make a copy.
> > > >
> > > > You don't need any zend_hash_xxx functions to just return an 
> associative
> > > > array.
> > > >
> > > > -Rasmus
> > >
> > >
> > >
> >
> >
> > --
> > PHP Development Mailing List <http://www.php.net/>
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>--
>Markus Fischer,  http://guru.josefine.at/~mfischer/
>EMail: [EMAIL PROTECTED]
>PGP Public  Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
>PGP Fingerprint: D3B0 DD4F E12B F911 3CE1  C2B5 D674 B445 C227 2BD0
>   -All your scripts are belong to Zend-
>
>--
>PHP Development Mailing List <http://www.php.net/>
>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 <http://www.php.net/>
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: use indent instead of fixing whitespace "by hand"?

[Zeev Suraski]

At 14:31 12-08-01, Thies C. Arntzen wrote:

> guys,
>
> it's really time to setup our "own" indent(1L) profile and
> simply run everything in php4/ thru it. i'll spend some time
> playing with it (while i'm on vacation) unless:
>
> does anybody see a reason *not* to swicht to indent (manybe
> even intergrated into out CVS) once we have a satisfying
> settings for it?
>
> please speak up now - i really don't want to waste my time on
> it if somebody has a good technical reason why this (running
> php-sources thru indent) won't work.

I think it can be a very good thing, even though it may get a bit tough, 
it's probably worth trying.
Things to watch for:
- We have to make a list of each and every last data type that is being 
defined or used in the php4 source tree.  It's going to be a bitch :)
- We need to see whether indent knows how to properly handle macros that 
create function prototypes, etc.  As we use macros extensively, if it can't 
handle them too well, it can probably rule it out.

I vaguely remember bumping into trouble with indent a couple of years ago 
(as you may know, we did use to have a 'make indent' configuration in the 
php3 days).  I don't remember if it was a dead end, or just something I 
didn't have the mental strength to deal with back then...

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] $_SESSION

[Zeev Suraski]

Were/are the register_global entries and $HTTP_SESSION_VARS[] entries 
references to each other or not?

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 /ext/sablot php_sablot.h

[Zeev Suraski]

At 14:03 13-08-01, Sterling Hughes wrote:
> Just to clarify -- I don't think the issue should be ignored -- I
> just feel that php-dev@ is not the appropriate place for such stuff.
> Take it up on group@, or find some place else to deal with it
> (or perhaps another developer meeting where these issues could really
> be worked on, face to face?)

I don't really agree (the only relevant forum is php-dev in my opinion, 
group is only for administrative stuff), but let's give it a rest for now.

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 /ext/sablot php_sablot.h

[Zeev Suraski]

At 19:06 12-08-01, Zeev Suraski wrote:
>I don't think that this happens too often - I think that comments like 
>Sebastian's are much more

Ick, Sterling's that is.  Sorry Sebastian ;)

Zeev


-- 
PHP Development Mailing List <http://www.php.net/>
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 /ext/sablot php_sablot.h

[Zeev Suraski]

At 17:31 10-08-01, Andrei Zmievski wrote:
>On Fri, 10 Aug 2001, [EMAIL PROTECTED] wrote:
> > This is not about renaming, it's about removing duplicate macro's.
>
>Of course it's about renaming. We used to have just PHP_* macros and
>then Zeev added the ZEND_* versions and now PHP_* ones are just aliased
>to ZEND_* ones for "backwards compatibility".

 From a technical perspective, if I change the prototype of the activation 
function, which is obviously in the engine, how does it make sense that 
I'll have to change macros outside the engine, instead of changing them 
inside the engine?  Or worse, change them in two places?

If there's more Zend-o-phobia, we can have #define PHP_* ZEND_* for some 
Zend macros.  I see a benefit in having modules compile independently of 
PHP so that they can plug into the stand alone engine in the future, but 
frankly, I don't care too much - we can move them to php.h instead of 
php3_compat.h.  It doesn't change the fact that the replicated macros had 
to go.

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]