Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0.

[Andi Gutmans]

At 03:19 AM 7/12/2001 +0200, Piotr Pawlow wrote:
>"Brian Moon" <[EMAIL PROTECTED]> wrote:
> > I am -1 on yet another new function.  Because, if you create a new
> > include_local or whatever, people are gonna want include_local_once
> > and so on and so forth.
>
>What do you say about include local($str), include_once local($str) ?
>Just one new function, no more :-) (of course the function name should
>be different, but I can't figure out a good name right now :-)
>I think that this include 'bug' should be fixed long before, now it is
>too late for changes. IMHO it would break many scripts.

Have you checked the latest CVS? I think I have fixed the problem. In any 
case, having a function which gives you the path as a result of the path of 
the executing script might not be such a bad idea.

Andi


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

Re: [PHP-DEV] Help with corrupted defines [bug 11990]

[Andi Gutmans]

Brian,

In order to debug this you'd really need to try and cut it down to a 
smaller reproducible script.
Maybe the best start for you is to compile with --enable-debug and see if 
you get any error messages from the memory manage in your error_log file 
about memory overruns and stuff. That could be a good first step.

Andi

At 10:32 AM 7/12/2001 -0700, Brian Lalor wrote:
>Hey all.  I haven't seen any further traffic on this issue (aside from
>myself, that is :-) ).  At one point yesterday, we were seeing an
>approximate 5% failure rate; 5% of pages served had errors due to garbage
>for a define.
>
>I spent some time poking about the PHP and Zend source yesterday and was
>able to call a php_printf() whenever a constant was defined as a string.
>Yeah, big deal, I know, but I'm thinking of using that method to verify
>that what's going into the hash table is what I've put in the script.
>
>Is there a way to dump an arbitrary Zend hash table from a PHP script?
>
>I've tried stepping through the entire execution of a PHP script with GDB.
>Not a pretty thing, as I'm sure most of you know.  I'm not able to
>determine even where the line
> define("FOO", "bar");
>is read from the file.
>
>Somewhere, the data for the defined constant is getting corrupted.  I
>don't know enough about the Zend internals to checkpoint the data at
>various points to see if it matches what I expect.  The other problem is
>that I can't reliably reproduce the error with a compact script or series
>of scripts, which is a major bummer for all involved.
>
>Would someone with the knowledge of the internals of PHP and Zend be
>willing to spend some time one-on-one with me any my team trying to get a
>solution to this?
>
>Thanks,
>B
>
>--
>Brian Lalor
>[EMAIL PROTECTED]
>(v) 480-333-3196
>(f) 480-760-9298
>
>
>--
>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] Is this a bug?

[Andi Gutmans]

At 11:47 AM 7/20/2001 +0200, Sebastian Bergmann wrote:
>  class foo {
> function bar() {
> print 'bar() called';
> }
> }
>
> $foo = new foo();
> $bar =& $foo;
> $method = 'bar';
>
> $foo->$method;   // does not work
> $bar->$method;   // does not work

This should be $foo->$method() and $bar->$method()

> call_user_method($method, $foo); // works
> call_user_method($method, $bar); // works
> ?>
>
>   I think this is a bug, and all four ways to invoke the method must
>have worked at some time in the past (I tested with latest 4.0.7-dev
>CVS on Win32), since PEAR uses the first/second method to invoke its
>'emulated destructors'.
>
>--
>   Sebastian Bergmann Measure Traffic & Usability
>   http://sebastian-bergmann.de/http://phpOpenTracker.de/
>
>--
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]


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

Re: [PHP-DEV] Is this a bug?

[Andi Gutmans]

At 02:31 PM 7/20/2001 +0200, Sebastian Bergmann wrote:
>Andi Gutmans wrote:
> > > $foo->$method;   // does not work
> > > $bar->$method;   // does not work
> >
> > This should be $foo->$method() and $bar->$method()
>
>   Gotcha. This works fine.
>   How could I forget the braces?

I don't quite understand. Why not write them? :)

Andi


-- 
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] Moving output.c from ext/standard to main/

[Andi Gutmans]

I only know of commercial products such as Rational Clearcase (which is far 
superior to CVS but very expensive) that handle stuff like directory 
versioning in a great way. It's not suitable for open-source projects though.
I also check into the tigris homepage every couple of months who are 
supposed to be working on a version of CVS which try to address some of the 
problems with CVS but they seem to be moving forward very slowly.

Andi


At 09:08 AM 7/20/2001 -0500, Jason Greene wrote:
>It a shame that CVS doesn't have a way to handle things like this..
>Are there commercial systems that can?
>
>-Jason
>
>- Original Message -
>From: "Zeev Suraski" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Sent: Friday, July 20, 2001 8:14 AM
>Subject: [PHP-DEV] Moving output.c from ext/standard to main/
>
>
> > It's been bugging me for over a year now, and I'm now trying to figure out
> > the best way to do it.  output.c sits today in ext/standard, which is
> > wrong, as it's really a part of the inner core of PHP, and not a set of
> > functions.
> > If I move the file in the CVS repository and fix the references, then
> > everything would be fine, history would be retained, except checking out
> > old CVS's will no longer work.
> > If import the file into main/ and delete it from ext/standard, we lose the
> > history for it, which is sucky.
> > I'm thinking about moving the file in CVS, and in addition to fixing the
> > HEAD branch, fix also the 4.0.6 branch, so that we at least can check out
> > one version back.  What do you guys think?
> >
> > 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 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] Moving output.c from ext/standard to main/

[Andi Gutmans]

At 12:27 PM 7/20/2001 -0400, Jon Parise wrote:
>On Fri, Jul 20, 2001 at 04:14:21PM +0300, Zeev Suraski wrote:
>
> > It's been bugging me for over a year now, and I'm now trying to figure out
> > the best way to do it.  output.c sits today in ext/standard, which is
> > wrong, as it's really a part of the inner core of PHP, and not a set of
> > functions.
> > If I move the file in the CVS repository and fix the references, then
> > everything would be fine, history would be retained, except checking out
> > old CVS's will no longer work.
> > If import the file into main/ and delete it from ext/standard, we lose the
> > history for it, which is sucky.
> > I'm thinking about moving the file in CVS, and in addition to fixing the
> > HEAD branch, fix also the 4.0.6 branch, so that we at least can check out
> > one version back.  What do you guys think?
>
>I'm pretty sure the correct way to do this is:
>
> Copy output.c,v from ext/standard/ to main/
> 'cvs remove output.c' from ext/standard/ in the HEAD branch
> Update all affected Makefile's, etc. and commit them to HEAD
>
>That should preserve the file's history and retain compatibility
>with old versions / branches.

We should do this in future too. We have renamed files in the past the 
*bad* way (just moving it in the cvs repository and not cp'ing it).

Andi


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

Fwd: [PHP-DEV] * New Parameter Parsing Functions *

[Andi Gutmans]

Guys,

Andrei sent this Email a while ago and I don't remember anyone giving 
feedback. We'd be happy to hear what people think about this new parameter 
API in the Zend Engine. I think it has good potential especially for 
simplifying functions which accept read-only arguments (which is the case 
for most functions) of pre-determined types.
Please take another look at what Andrei wrote and see what you think.
Andi


>Date: Tue, 10 Jul 2001 10:35:04 -0500
>From: Andrei Zmievski <[EMAIL PROTECTED]>
>To: PHP Developers <[EMAIL PROTECTED]>
>User-Agent: Mutt/1.2.5i
>Subject: [PHP-DEV] * New Parameter Parsing Functions *
>
>New parameter parsing functions
>===
>
>It should be easier to parse input parameters to an extension function.
>Hence, borrowing from Python's example, there are now a set of functions
>that given the string of type specifiers, can parse the input parameters
>and store the results in the user specified variables. This avoids most
>of the IS_* checks and convert_to_* conversions. The functions also
>check for the appropriate number of parameters, and try to output
>meaningful error messages.
>
>
>Prototypes
>--
>/* Implemented. */
>zend_parse_parameters(int num_args, char *type_spec, ...);
>zend_parse_parameters_ex(int flags, int num_args, char *type_spec, ...);
>
>/* Not implemented yet. */
>zend_parse_parameters_hash(HashTable *ht, char *type_spec, ...);
>zend_parse_parameters_hash_ex(int flags, HashTable *ht, char *type_spec, ...);
>
>
>The zend_parse_parameters() function takes the number of parameters
>passed to the extension function, the type specifier string, and the
>list of pointers to variables to store the results in. The _ex() version
>also takes 'flags' argument -- current only ZEND_PARSE_PARAMS_QUIET can
>be used as 'flags' to specify that the function should operate quietly
>and not output any error messages.
>
>The auto-conversions are performed as necessary. Arrays, objects, and
>resources cannot be autoconverted.
>
>
>Type specifiers
>---
>  l  - long
>  d  - double
>  s  - string (with possible null bytes) and its length
>  b  - boolean, stored in zend_bool
>  r  - resource (stored in zval)
>  a  - array
>  o  - object (of any type)
>  O  - object (of specific type, specified by class entry)
>  z  - the actual zval
>
>  The following characters also have a meaning in the specifier string:
>  | - indicates that the remaining parameters are optional, they
> should be initialized to default values by the extension 
> since they
> will not be touched by the parsing function if they are not
> passed to it.
> / - use SEPARATE_ZVAL_IF_NOT_REF() on the parameter it follows
> ! - the parameter it follows can be of specified type or NULL 
> (only applies
>  to 'a', 'o', 'O', 'r', and 'z'). If NULL is passed, the results
> pointer is set to NULL as well.
>
>Examples
>
>/* Gets a long, a string and its length, and a zval */
>long l;
>char *s;
>int s_len;
>zval *param;
>zend_parse_parameters(ZEND_NUM_ARGS(), "lsz", &l, &s, &s_len, ¶m);
>
>
>/* Gets an object of class specified by my_ce, and an optional double. */
>zval *obj;
>double d = 0.5;
>zend_parse_parameters(ZEND_NUM_ARGS(), "O|d", &obj, my_ce, &d);
>
>
>/* Gets an object or null, and an array.
>If null is passed for object, obj will be set to NULL. */
>zval *obj;
>zval *arr;
>zend_parse_parameters(ZEND_NUM_ARGS(), "O!a", &obj, &arr);
>
>
>/* Gets a separated array. */
>zval *arr;
>zend_parse_parameters(ZEND_NUM_ARGS(), "a/", &arr));
>
>
>/* Get only the first three parameters (useful for varargs functions). */
>zval *z;
>zend_bool b;
>zval *r;
>zend_parse_parameters(2, "zbr!", &z, &b, &r);
>
>
>/* Get either a set of 3 longs or a string. */
>long l1, l2, l3;
>char *s;
>if (zend_parse_parameters_ex(ZEND_PARSE_PARAMS_QUIET, ZEND_NUM_ARGS(), 
>"lll", &l1, &l2, &l3)) {
> /* manipulate longs */
>} else if (zend_parse_parameters_ex(ZEND_PARSE_PARAMS_QUIET, 
>ZEND_NUM_ARGS(), "s", &s)) {
> /* manipulate string */
>} else {
> /* output error */
>}
>
>Comments and feedback are welcome.
>
>-Andrei
>* If it's never finished, you can't prove it doesn't work. *
>
>--
>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] parent/super??

[Andi Gutmans]

At 10:03 PM 7/20/2001 -0600, Chris Newbill wrote:
>Hope I am not opening a can of worms here, but...
>
>Did anything become final on whether or not super::foo() would work?  I'm
>looking through the mail list archives and can't find a definate answer.
>
>If the answer is 'no', that's fine I can work around it easily, would just
>be nice to have  every now and then.

parent:foo() works.

Andi


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

Re: [PHP-DEV] Fw: PHP XMF

[Andi Gutmans]

At 07:36 PM 7/21/2001 -0700, Rasmus Lerdorf wrote:
> > I wan to thank you for making your quick decision.
>
>Well, there is no point wasting your time.  If we were going to push a
>single content management framework as the standard PHP framework which in
>itself it quite unlikely, then we would pick one of the established ones
>written by people with a history in the PHP community and an understanding
>of that community.
>
>Content-management is outside the scope of the PHP project.  It may fit
>within the scope of the PEAR project at some point.
>
>And you cannot alienate most non-Windows users by flatly stating that you
>won't support Netcape.  How can you position something as a generic
>framework if 10-15% of all web users are not eligible to use it?

Rasmus,

Why would the fact that Michael isn't interested in supporting Netscape by 
himself stop this from becoming a PHP community project? I think the whole 
idea of making this a php.net/PEAR project would be that others from the 
community would help improve it and it would become what people want it to 
become.
I actually think he has a point that we should strive to create one good 
framework for PHP. This is very much like PEAR trying to give people good 
framework/class solutions.
Why are you being so completely against without letting the rest of php-dev 
& pear-dev discuss it? "Ok, then you have made our decision quite easy.". 
Who is "our"?
Anyway, I'm not saying that this PHP XMF needs to necessarily become the 
basis but I think it'd be a good idea to pitch this to the PEAR guys and 
see what they think about it (cc'ed them). I'm sure that if the pear guys 
would take such a project under their hood it would work with Netscape 
within a few weeks. Working or not working with Netscape is not a reason 
for not taking something as a starting baseline IMO.

Andi


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

Re: [PHP-DEV] Fw: PHP XMF

[Andi Gutmans]

At 10:10 PM 7/21/2001 -0700, Rasmus Lerdorf wrote:
> > I actually think he has a point that we should strive to create one good
> > framework for PHP. This is very much like PEAR trying to give people good
> > framework/class solutions.
>
>If you had read my message you would have seen that I suggested it may fit
>within PEAR.  He was asking for cmf.php.net though which I just don't see
>happening.
>
>And frankly, looking at the quality of his site compared to other content
>management frameworks out there, I don't see his being at the top of the
>heap.  That doesn't mean it couldn't be one day.  But if you are seriously
>suggesting saying "yes" at this point and setting up cmf.php.net for him
>and basically framing his system as *the* PHP content management system,
>then please say so.

I don't think we need to say "no" before the PEAR guys take a look at it 
and maybe discuss it in more detail with the author. I just didn't 
understand the rush of you saying "no" without waiting for others to 
respond and discussing it in more details. We might come to the conclusion 
that it's a lousy idea but I prefer coming to that conclusion hearing other 
opinions too. We might come to a conclusion that if a zillion things are 
changed it might be nice to have. Or the discussion might spawn a new Pear 
framework.

Andi


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

Re: [PHP-DEV] Fw: PHP XMF

[Andi Gutmans]

At 10:31 PM 7/21/2001 -0700, Rasmus Lerdorf wrote:
> > I don't think we need to say "no" before the PEAR guys take a look at it
> > and maybe discuss it in more detail with the author. I just didn't
> > understand the rush of you saying "no" without waiting for others to
> > respond and discussing it in more details. We might come to the conclusion
> > that it's a lousy idea but I prefer coming to that conclusion hearing other
> > opinions too. We might come to a conclusion that if a zillion things are
> > changed it might be nice to have. Or the discussion might spawn a new Pear
> > framework.
>
>If it was remotely competitive with something like Midgard I would tend to
>agree.  But it is just so far behind.  But sure, if the PEAR folks can be
>convinced, great.

I don't want to convince anyone :) I have no personal interest in this. I 
just thought it was odd that I wake up and whilst reading my EMails the 
issue was settled already w/o anyone responding.
I just prefer having more people give a "no" so that we can give a real 
final "no".
Anyway, let's just see if someone in php-dev/pear thinks it's interesting. 
If not, we should leave it as your "no".

Andi


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

Re: [PHP-DEV] Latest CVS on Linux with Apache 1.3.20

[Andi Gutmans]

Did you update TSRM & Zend?

Andi

At 09:21 PM 7/28/2001 +0200, Sebastian Bergmann wrote:
>   Cannot load /usr/local/apache/libexec/libphp4.so into server:
>   undefined symbol: TSRMLS_FETCH
>
>   ./configure --enable-inline-optimization
>   --with-apxs=/usr/local/apache/bin/apxs
>   --with-mysql=/usr/local/mysql
>   --with-pgsql
>   --with-zlib=/usr
>   --without-pear
>
>--
>   Sebastian Bergmann Measure Traffic & Usability
>   http://sebastian-bergmann.de/http://phpOpenTracker.de/
>
>--
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
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] Security Issues

[Andi Gutmans]

Hey,

I thought of an idea yesterday which could make everyone happy. In the 
default php.ini we set the register_globals to a new value "unset". If PHP 
runs with this INI value it will display a page telling you that you need 
to define the register_globals option in your php.ini and explains the 
pros/cons & security concerns involved (IMO we should recommend 
register_globals=off). This way we won't break existing sites which already 
have php.ini and we have an easy way to feed new users w/ the required 
information.
Of course, I still think we should think of a nicer way to access form 
variables such as $_FORM[] in order to make it easier for the developer.

Andi


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

Re: [PHP-DEV] Question about socket ext. file descriptors

[Andi Gutmans]

At 12:44 PM 3/29/2001 -0800, Lars Torben Wilson wrote:

>Slightly different topic--is it a problem that call-time pass-by-ref
>is being deprecated but several functions require it in order to work?

It is possible. Functions which require their argument by reference should 
ask for it to be sent by reference and not expect the calling person to 
write foo(&$bar). The BY_REF_ALLOW is a remainder of PHP 3 and is obsolete 
with today's reference counting (I'm pretty sure about this but I just woke 
up so I might be saying BS :).

Andi


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

Re: [PHP-DEV] fastcgi

[Andi Gutmans]

I don't have time to look at it but the error about sapi_globals use 
SLS_FETCH(); in the beginning of that function.
The S_ISREG is defined in fopen-wrappers.c. We should probably move it to 
someplace more central so that other files see it (it exists on some 
systems automagically but not on Windows).
And of course, fork() doesn't exist on Windows. No time to go and look at 
why it is used.

Andi


At 07:14 PM 3/29/2001 +0100, James Moore wrote:
>Ive been having a play with fastcgi under win32 and what ever I do I seem to
>get the following errors:
>
>Compiling...
>fastcgi.c
>D:\php-4.0.5RC4\sapi\fastcgi\fastcgi.c(103) : warning C4101: 'tmp' :
>unreferenced local variable
>D:\php-4.0.5RC4\sapi\fastcgi\fastcgi.c(181) : error C2065: 'sapi_globals' :
>undeclared identifier
>D:\php-4.0.5RC4\sapi\fastcgi\fastcgi.c(181) : error C2223: left of
>'->request_info' must point to struct/union
>D:\php-4.0.5RC4\sapi\fastcgi\fastcgi.c(185) : warning C4047: 'function' :
>'struct sapi_globals_struct *' differs in levels of indirection from 'int '
>D:\php-4.0.5RC4\sapi\fastcgi\fastcgi.c(185) : warning C4024:
>'php_request_startup' : different types for formal and actual parameter 4
>D:\php-4.0.5RC4\sapi\fastcgi\fastcgi.c(219) : warning C4013: 'S_ISREG'
>undefined; assuming extern returning int
>D:\php-4.0.5RC4\sapi\fastcgi\fastcgi.c(259) : error C2223: left of
>'->server_context' must point to struct/union
>D:\php-4.0.5RC4\sapi\fastcgi\fastcgi.c(264) : error C2223: left of
>'->server_context' must point to struct/union
>D:\php-4.0.5RC4\sapi\fastcgi\fastcgi.c(350) : warning C4013: 'fork'
>undefined; assuming extern returning int
>D:\php-4.0.5RC4\sapi\fastcgi\fastcgi.c(370) : warning C4013: 'wait'
>undefined; assuming extern returning int
>D:\php-4.0.5RC4\sapi\fastcgi\fastcgi.c(403) : error C2143: syntax error :
>missing ')' before ','
>D:\php-4.0.5RC4\sapi\fastcgi\fastcgi.c(403) : error C2198:
>'init_request_info' : too few actual parameters
>D:\php-4.0.5RC4\sapi\fastcgi\fastcgi.c(403) : error C2059: syntax error :
>')'
>D:\php-4.0.5RC4\sapi\fastcgi\fastcgi.c(404) : error C2223: left of
>'->server_context' must point to struct/union
>D:\php-4.0.5RC4\sapi\fastcgi\fastcgi.c(405) : error C2065:
>'compiler_globals' : undeclared identifier
>D:\php-4.0.5RC4\sapi\fastcgi\fastcgi.c(406) : error C2223: left of
>'->request_info' must point to struct/union
>D:\php-4.0.5RC4\sapi\fastcgi\fastcgi.c(409) : error C2143: syntax error :
>missing ')' before ','
>D:\php-4.0.5RC4\sapi\fastcgi\fastcgi.c(409) : error C2059: syntax error :
>')'
>Error executing cl.exe.
>
>Is this just me being totally stupid and not defining somthing I should or
>is there actually somthing wrong? or wont it work on win32?
>
>James
>--
>James Moore
>[EMAIL PROTECTED]
>PHP Web Scripting: http://www.php.net/
>PHP QA Team: http://qa.php.net/
>PHP-GTK: http://gtk.php.net/
>VL-SRM: http://www.vl-srm.net/
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP 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] PHP 4.0.5 Release & Midgard Problems

[Andi Gutmans]

I very much liked Andrei's implementation of Smary templates. It uses the 
Zend (PHP) scripting language and caches templated scripts without messing 
with the core of PHP.
I haven't used it but from reading the specs it looks like Andrei & his 
guys did a great job.

Andi

At 11:10 AM 4/1/2001 +0300, Alexander Bokovoy wrote:
>On Sun, Apr 01, 2001 at 09:07:44AM +0200, Sebastian Bergmann wrote:
> > Alexander Bokovoy wrote:
> > > Ask Zend folks, they have our proposals, even C code to Zend engine
> > > to implement native templating with no connection to Midgard at all -
> > > this system was designed to be generic for any template providers.
> >
> >   Does this have to be implemented in the ZendEngine or would a
> > ext/template extension (for instance) be possible, also? This would be
> > great, though Template Engines are a dying species with the advent of
> > XSLT, IMHO.
>Not so simple because XSLT is far than complex for lot of applications and
>especially when you are trying to provide content edit capabilities for
>non-techies. This is huge nische.
>
>It most effective at ZendEngine level but actually task is two-tiered. Let 
>me describe:
>1. Templating require additional syntax which is better handled by ZendEngine
>2. Syntax provides access to collection of template elements and manipulation
>of them. It's up to template provider to collect template elements from
>some source(s) before actual template building. This is better handled by
>extensions.
>
>This separation also allows to make complex transitions like
>'document with template markup' -> XML-based source + XSLT -> output
>In this case second step is done by Template Provider which provides
>template elements + hooks to translate them to XML + output callbacks.
>Zend Engine dispatches these calls via easy user-oriented syntax.
>
>For example, in Midgard we have two kinds of template calls:
><[template element]> -- just insert content of template element here and 
>evaluate it as PHP code.
> It looks like hidden functional call to include() 
> but the difference
> is that 'template element' actually can come from 
> completely
> different place than file system (in Midgard it 
> comes from Database
> or FileTemplates).
>&(variable:formatter); -- pass $variable throught existing formatter and 
>insert
> output into output stream. Different formatters allow
> to convert plain text to HTML with different 
> levels of
> formatting, execute PHP code, execute 
> user-defined formatter
> against $variable. Variable could be any PHP 
> structure
> (scalar, object, array, etc)
>
>These are very simple constucts, but they are greatly reduce build-up for 
>non-technical
>interfaces.
>--
>Sincerely yours, Alexander Bokovoy
>   The Midgard Project| ALT  Linux  Team | Minsk Linux Users Group
>  www.midgard-project.org | www.altlinux.ru  |www.minsk-lug.net
>-- Success is in the minds of Fools.
> -- William Wrenshaw, 1578
>
>--
>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] Can we have a "PING" function?

[Andi Gutmans]

Do most servers and OS's (for example Windows) support the sending of a UDP 
package to the echo port?

Andi

At 12:39 AM 4/2/2001 -0400, Dave Crawford wrote:
>Before I ask for a PING function in a future build of PHP, is there a
>way to ping a remote host using the existing PHP functions or modules?
>
>Based on my knowledge gained from various sources and php.net's online
>functional reference, there does not appear to be much support for LWP
>anything.
>
>I would like to know how to do, or perhaps you can build a function
>in a future release that can do basically the same thing as outlined in the
>following document for a similar function in Perl:
>http://www.perl.com/pub/doc/manual/html/lib/Net/Ping.html
>
>When my site was all html and Perl, I used this function to ping all of my
>mirror download sites, and I coloured the ping value based on a range
>(Ex: less than 150ms was green, greater than 600ms was red, etc.)
>
>I need a way to incorperate this same functionality into my new all PHP
>based website.
>
>Thanks.
>-Dave
>
>
>
>--
>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] mail.c

[Andi Gutmans]

Seems to me like these lines can be erased. ext/standard is always compiled 
in and doesn't really need ZEND_GET_MODULE() and in any case 
ZEND_GET_MODULE(odbc) seems bogus :)

Andi

At 04:35 PM 4/2/2001 +0100, James Moore wrote:
>I was just reading through mail.c and this stuck out to me as seeming a
>little strange.. can anyone explain it??
>
>(lines 43-46)
>#ifdef COMPILE_DL_STANDARD
>ZEND_GET_MODULE(odbc)
>#endif
>
>Why is it odbc? is this a careless ctrl-c ctrl-v someone has done or should
>it actually be this?
>
>cheers,
>
>James
>
>
>--
>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-QA] PHP 4.0.5 Release Candidate testing

[Andi Gutmans]

Andrei,

Can you please merge this to 4.0.5. I think it should be in and we better 
release a final RC6.
I think it's better to have another quick RC (I can roll it today or 
tomorrow) before we get 4.0.5 out of the door.
Andi

At 08:25 AM 4/2/2001 -0500, Andrei Zmievski wrote:
>On Mon, 02 Apr 2001, Alexander Feldman wrote:
> > Hi,
> >
> > These are the results and questions from some tests I run yesterday on the
> > last 4.0.5 release candidate. Note that all differences are from PHP
> > 4.0.4pl1.
> >
> > 1. The function array_flip($array) puts one extra zero byte at the end of
> > each element in the return array thus making the result non binary safe.
>
>I've just fixed it in CVS.
>
> > 3. The count_chars() function returns different result from the 4.0.4pl1
> > count_chars() function.
>
>Examples?
>
>-Andrei
>
>"The only true currency in this bankrupt world is what we share with each
>other when we're uncool." -- Lester Bangs, from the film 'Almost Famous'
>
>--
>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-QA] PHP 4.0.5 Release Candidate testing

[Andi Gutmans]

Thanks!
Does anyone else have any critical bug fixes which need to be in 4.0.5? (I 
mean critical ones and not huge patches).

Andi

At 11:17 AM 4/2/2001 -0500, Andrei Zmievski wrote:
>It's done.
>
>On Mon, 02 Apr 2001, Andi Gutmans wrote:
> > Andrei,
> >
> > Can you please merge this to 4.0.5. I think it should be in and we better
> > release a final RC6.
> > I think it's better to have another quick RC (I can roll it today or
> > tomorrow) before we get 4.0.5 out of the door.
> > Andi
>
>
>
>-Andrei
>* Non-volatile, random-access, analog memory store... a book. *


-- 
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] Can we have a "PING" function?

[Andi Gutmans]

Maybe Dave will volunteer to implement this for 4.0.6 :)

Andi

At 10:42 AM 4/2/2001 +0200, Alexander Feldman wrote:
> > Do most servers and OS's (for example Windows) support the sending of a 
> UDP
> > package to the echo port?
> >
> > Andi
>
>Yeah,
>
>What about a new ICMP extension - ping, traceroute, etc.
>
>-- Alex
>
> >
> > At 12:39 AM 4/2/2001 -0400, Dave Crawford wrote:
> > >Before I ask for a PING function in a future build of PHP, is there a
> > >way to ping a remote host using the existing PHP functions or modules?
> > >
> > >Based on my knowledge gained from various sources and php.net's online
> > >functional reference, there does not appear to be much support for LWP
> > >anything.
> > >
> > >I would like to know how to do, or perhaps you can build a function
> > >in a future release that can do basically the same thing as outlined 
> in the
> > >following document for a similar function in Perl:
> > >http://www.perl.com/pub/doc/manual/html/lib/Net/Ping.html
> > >
> > >When my site was all html and Perl, I used this function to ping all of my
> > >mirror download sites, and I coloured the ping value based on a range
> > >(Ex: less than 150ms was green, greater than 600ms was red, etc.)
> > >
> > >I need a way to incorperate this same functionality into my new all PHP
> > >based website.
> > >
> > >Thanks.
> > >-Dave
> > >
> > >
> > >
> > >--
> > >PHP Development Mailing List 
> > >To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >For additional commands, e-mail: [EMAIL PROTECTED]
> > >To contact the list administrators, e-mail: [EMAIL PROTECTED]
> >
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > To contact the list administrators, e-mail: [EMAIL PROTECTED]
> >


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

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] PHP 4.0.5 Release Candidate testing

[Andi Gutmans]

At 05:37 PM 4/2/2001 +0100, Anil Madhavapeddy wrote:
>Andi Gutmans wrote:
>
> > Does anyone else have any critical bug fixes
> > which need to be in 4.0.5? (I mean critical ones and not
> > huge patches).
>
>Zeev's output buffering fix hasn't been committed yet; it's a one-line
>change, and it makes the transparent output compression stuff work.

I suggest you merge this into 4.0.5 because it seems to me that otherwise 
output buffering will be quite a mess without it. It would be a shame to 
release 4.0.5 without it.


>Does anyone have any objection to an MFH on the small Vary header patch
>also?  It improves PHP's RFC2616 compliance, but it also unbreaks almost
>every web-cache, which rely on having it present for content-negotiated
>pages.

Your fix looks OK but I'd like to hear the opinion of someone else who is 
more familiar with RFC2616.

Andi


-- 
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: [PHP-QA] PHP 4.0.5 Release Candidate testing

[Andi Gutmans]

At 03:18 PM 4/2/2001 +0100, James Moore wrote:
> > > 1. The function array_flip($array) puts one extra zero byte at
> > the end of
> > > each element in the return array thus making the result non binary safe.
> >
> > I've just fixed it in CVS.
>
>How critical is this? does it need to also be in 4.0.5 (sorry Zeev ;))

Yes, I think it should be in 4.0.5
And the output buffering patch of Zeev should be in there too. Hopefully 
RC6 will be the last RC. Better another RC than a pl1.

Andi


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

[PHP-DEV] RC6

[Andi Gutmans]

I'm going to package RC6 later today so if there are any problems scream!

Andi


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

[PHP-DEV] RC6 available!

[Andi Gutmans]

You can get RC6 at http://cvs.php.net/~andi/php-4.0.5RC6.tar.gz (no time to 
commit to phpweb cvs and wait for it to update, if someone has time then 
even better, I need some sleep :)
In case you're testing it within the next few hours you might need to 
"touch *" the files in the php4/ directory because of timezone differences 
(didn't anyone get bitten by this in the past? ).

Anyway, as usual, please test it on all the platforms you have. Try not to 
find bugs but if you do then let everyone know.

Happy testing. Hopefully this is the last RC but remember the most 
important thing is to have a stable release.

Andi


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

[PHP-DEV] Re: [PHP-QA] PHP-4.0.5-RC6

[Andi Gutmans]

Anyone have an idea why this happens?

Andi

At 05:37 PM 4/3/2001 +0200, Andrew Sitnikov wrote:
>Hello php-qa,
>
>   test.php
>echo $test;
>   ?>
>
>   http://host/test.php?test=1;2;3
>
>
>   4.0.4pl1
>   Result: 1;2;3
>
>   4.0.5RC6
>   Result: 1
>
>
>Best regards,
>  Andrew Sitnikov
>  e-mail : [EMAIL PROTECTED]
>  GSM: (+372) 56491109
>
>
>
>--
>PHP Quality Assurance Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]


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

Re: [PHP-DEV] Re: [PHP-QA] PHP-4.0.5-RC6

[Andi Gutmans]

It might be valid but we might be breaking many people's sites.
I am not sure this is a very good idea.
Is it configurable via php.ini? We could keep the default the old behavior.

Andi

At 06:35 PM 4/3/2001 +0100, Anil Madhavapeddy wrote:
>It's the arg_separator changes isn't it?  Both '&' and ';' are valid
>delimiters in a URL, so the new 4.0.5 behaviour is actually the valid one, I
>believe.  Refer to the XHTML specification, or check out the bugs db for
>this.
>
>Anil
>
>- Original Message -
>From: "Andi Gutmans" <[EMAIL PROTECTED]>
>To: "Andrew Sitnikov" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
>"php-dev mailinglist" <[EMAIL PROTECTED]>
>Sent: Tuesday, April 03, 2001 6:21 PM
>Subject: [PHP-DEV] Re: [PHP-QA] PHP-4.0.5-RC6
>
>
> > Anyone have an idea why this happens?
> >
> > Andi
> >
> > At 05:37 PM 4/3/2001 +0200, Andrew Sitnikov wrote:
> > >Hello php-qa,
> > >
> > >   test.php
> > >> > echo $test;
> > >   ?>
> > >
> > >   http://host/test.php?test=1;2;3
> > >
> > >
> > >   4.0.4pl1
> > >   Result: 1;2;3
> > >
> > >   4.0.5RC6
> > >   Result: 1
> > >
> > >
> > >Best regards,
> > >  Andrew Sitnikov
> > >  e-mail : [EMAIL PROTECTED]
> > >  GSM: (+372) 56491109
> > >
> > >
> > >
> > >--
> > >PHP Quality Assurance 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]
> >
> >


-- 
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-QA] PHP-4.0.5-RC6

[Andi Gutmans]

At 10:01 PM 4/3/2001 +0200, Jani Taskinen wrote:
>On Tue, 3 Apr 2001, Zeev Suraski wrote:
>
> >My guess is that's the arg_separator fix.  Jani?
>
>Yes, that's true. I did ask (couple of times) before
>I committed that patch. And yes, now both & and ; are
>considered as arg separators.
>
>And I'd like to think that it's a feature than bug. ;)

Yes I understand but it's not always so clear cut especially not when you 
can break a lot of scripts. There is always a trade-off between backwards 
compatibility and doing the right thing. Is this configurable in php.ini? 
I'm not familiar with the patch itself (couldn't find the CVS diff).


>This url explains why it's considered a good thing:
>http://www.w3.org/TR/html4/appendix/notes.html#h-B.2.2
>
>If this breaks someone's scripts, that's their fault.. >:-)
>(ie. they should be using urlencode() on the urls if they
>contain illegal chars..)
>
>--Jani
>
>
> >At 19:21 3/4/2001, Andi Gutmans wrote:
> >>Anyone have an idea why this happens?
> >>
> >>Andi
> >>
> >>At 05:37 PM 4/3/2001 +0200, Andrew Sitnikov wrote:
> >>>Hello php-qa,
> >>>
> >>>   test.php
> >>>>>> echo $test;
> >>>   ?>
> >>>
> >>>   http://host/test.php?test=1;2;3
> >>>
> >>>
> >>>   4.0.4pl1
> >>>   Result: 1;2;3
> >>>
> >>>   4.0.5RC6
> >>>   Result: 1
> >>>
> >>>
> >>>Best regards,
> >>>  Andrew Sitnikov
> >>>  e-mail : [EMAIL PROTECTED]
> >>>  GSM: (+372) 56491109
> >>>
> >>>
> >>>
> >>>--
> >>>PHP Quality Assurance 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 Quality Assurance 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-QA] Re: [PHP-DEV] Re: [PHP-QA] PHP-4.0.5-RC6

[Andi Gutmans]

James,

You have to be aware that now PHP has such a big user base we need to be 
very careful in the changes we make especially when we can be pretty 
certain that it might burn quite a lot of people. We can break 
compatibility more easily when we have a major release (as from PHP 3 to 
PHP 4) but these kind of patches need to also be sensitive to the existing 
users.
I personally don't know this issue very well and it is hard for me to guess 
how many people will be effected. Probably some of you who know this better 
can get an idea. Also I missed if this is the same directive as in php.ini.
Anyway, I'm just saying don't take the user base too lightly because most 
of them aren't php-dev@ hackers who want the standards but they want their 
web sites to continue working.
Anyway, this doesn't mean I am necessarily against including the patch but 
we need to make sure we're all OK with it and make a decision not only 
based on the standard but also on how much damage this might make.

Andi

At 09:22 PM 4/3/2001 +0100, James Moore wrote:

> > > Yes, that's true. I did ask (couple of times) before
> > > I committed that patch. And yes, now both & and ; are
> > > considered as arg separators.
> > >
> > > And I'd like to think that it's a feature than bug. ;)
> >
> > That would be true, if PHP would be some kind of reference
> > implementation.  But we don't exist to force standards down
> > our users' throats.
> >
> > It should be optional and default to off.
>
>Why shouldnt we require people to use legal url's?
>
>If we are conforming to standards, and I feel we should where possible (they
>are there for a reason.. by your argument why should dirname("/foo/") return
>/ rather than /foo, which, to most of us is the most obvious but as you
>pointed out earlier the standards say so..).
>
>If I come from some other language or where ever and expect test=1;2;3 to
>work someway and it works differently to the standards "just because it does
>and we dont want to ram standards down peoples throats" its going to piss me
>off. I agree it should be optional but should be defaulted to on.
>
>-James
>
>
>--
>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-QA] Re: [PHP-DEV] Re: [PHP-QA] PHP-4.0.5-RC6

[Andi Gutmans]

At 09:52 PM 4/3/2001 +0100, James Moore wrote:
>Well, I dont think any of us really know how much damage it will cause. But
>on the other hand we can do this for years and just say well we mustn't
>break backwards compatibility and we will end up with somthing looking and
>behaving like perl. When we have somthing as blantantly wrong as this it
>should be fixed.
>
>I would question about it being optional in the long term though. If we
>begin to make everything optional then we get to a point where PHP is so
>configurable with enabling this bug here or there it becomes impossible to
>create distribuable scipts that are easy to install and make work (making it
>difficult for commercial companies to create PHP Scripts to sell which is a
>bad thing IMHO).

I also prefer as little as possible to be configurable so that PHP 
applications written on one PHP installation will run on all others. I 
think configurability should be kept at a minimum. However, changing such 
behavior in a mini-version is not obvious. And when you say it's 
"blantantly wrong" the way it works today, well maybe it is, but we both 
know how many people really got bitten by this "blatantly wrong". Very few...

Andi


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

[PHP-DEV] Re: [PHP-QA] Re: ; arg seperator

[Andi Gutmans]

At 02:46 PM 4/3/2001 -0600, Joey Smith wrote:
>Just wanted to toss in my .02 here...
>
>Anyone who wrote scripts in the past expecting: foo.php?a=1;2;3 to get
>"$a=1;2;3" was relying on a bug, or at the very LEAST an undocumented
>feature. So if it goes away, it goes away. It should never have worked
>to begin with, IMHO...

Why? It was documented that & was the separator.


>This doesn't mean it won't bite some people, but that's never been a
>problem before in cases of undocumented features.

I don't think it was undocumented.

Andi


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

[PHP-DEV] Re: [PHP-QA] Re: ; arg seperator

[Andi Gutmans]

At 03:18 PM 4/3/2001 -0600, Joey Smith wrote:
>Speaking of this, I think we need to collect all of these types of
>issues that are waiting for a "4.1" release somewhere, so we can get a
>clear idea of when 4.1 is appropriate. Anyone know of any off-hand? If
>not, I can go search the archives...

In any case it is a good idea to make a list of these issues. I can't 
remember off hand what issues we had so I hope people have a better memory 
than me :)

Andi


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

Re: [PHP-DEV] Unix timestamp maximum

[Andi Gutmans]

By the time we close in on 2038 and UNIX is still around (*smile*) then 
most UNIX systems will most probably have moved to 64bit timestamps, thus 
requiring in the best place just a recompilation of your PHP binary and in 
the worse case if you saved binary file stamps to a file, some kind of 
conversion script. It's not as bad as the Y2K bug (which wasn't too bad:)

Andi

At 05:06 PM 4/4/2001 +0200, Keith Waters wrote:
>From: [EMAIL PROTECTED]
>Operating system: RedHat Linux
>PHP version:  4.0.4pl1
>PHP Bug Type: Feature/Change Request
>Bug description:  Unix timestamp doesnt go over Tuesday 19 January 2038
>05:11
>
>As you know, most of PHP's date and time functions use the unix
>timestamp, which wont go past Tuesday 19 January 2038 05:11, numberically
>represented by 2147483648 (ie 30 bits)
>
>Surely PHP can get clever and work around this? (ie allow bigger values
>which will translate back and forth properly up to the year ?)
>Otherwise we will all find outselves with a Y2K-like date nightmare!
>
>eg:  currently:  echo mktime(0,0,0,1,1,2099);  outputs -1
>and putting any number past 2147483648 into date() wont give you
>anything past Tuesday 19 January 2038 05:11
>
>Thanks!
>regards,
>Keith
>
>
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]


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

[PHP-DEV] What to do about 4.0.5

[Andi Gutmans]

OK guys,

I feel VERY uncomfortable releasing 4.0.5 with this arg_separators problem. 
Let's brainstorm and try to think of a nice, clean and constructive way of 
solving this problem. Let's try to ditch the "screw the user because he 
didn't read RFC foo.bar approach :)
The issue is with the arg_separator of incoming URL's. If we think of a 
nice solution we should probably make it look&feel similar to the solution 
we will have with URL's which are created.

Ideas? Thoughts?

Andi


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

Re: [PHP-DEV] What to do about 4.0.5

[Andi Gutmans]

At 05:40 PM 4/4/2001 +0200, Jani Taskinen wrote:
>On Wed, 4 Apr 2001, Andi Gutmans wrote:
>
> >I feel VERY uncomfortable releasing 4.0.5 with this arg_separators problem.
> >Let's brainstorm and try to think of a nice, clean and constructive way of
> >solving this problem. Let's try to ditch the "screw the user because he
> >didn't read RFC foo.bar approach :)
> >The issue is with the arg_separator of incoming URL's. If we think of a
> >nice solution we should probably make it look&feel similar to the solution
> >we will have with URL's which are created.
>
>We spoke with Zeev about this. We came to conclusion that
>there should be a php.ini directives like these:
>
>arg_separator.input=";&"
>arg_separator.output="&"
>
>Where defaults are:
>
>arg_separator.input="&"
>arg_separator.output="&"

Sounds like a good solution to me.
The places which used the old arg_separator seem to only be in main.c and 
url_scanner*.c
So we should update these and add support for the arg_separator.input.
I think that's really OK.

Andi


-- 
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: ; arg seperator

[Andi Gutmans]

At 07:11 PM 4/4/2001 +0200, Edin Kadribasic wrote:
> > But commercial companies aside, the plethora of configuration options
>(like
> > magic_quotes_gpc) can and does make life harder for people writing code
> > libraries (like PEAR) that are meant to be dropped in anywhere, or for
>people
> > trying to write applications that have minimal setup required, or that
>people
> > can install on hosts where they don't have access to the php.ini
>parameters.
> > It's certainly something to keep in mind.
>
>There was a discussion about things to break in 4.1. magic_quotes_gpc would
>definitely be my favourite. I'd like to see it set to off for good and
>removed from php.ini.
>Is anybody keeping notes ? ;)

I think you just volunteered yourself :)

Andi


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

Re: [PHP-DEV] 4.0.5 Comments change (leads to inappropriate parse error based on contents of comments)

[Andi Gutmans]

This was fixed to be consistent with ?>.
One line comments end at a new line or at a closing bracket (?> or %>)

Andi

At 05:54 PM 4/4/2001 -0700, Steven Roussey wrote:
>Hi,
>
>I found our problem. In 4.0.5, comments seem to be parsed differently. We
>have ASP style tags enabled so we can use %> as well as ?>. But we had
>comments like this:
>
>
>//asdfasdf%>asdfasdf
>echo('');
>?>
>
>< 4.0.5 would ignore the whole line. 4.0.5 still parses it for open and
>close tags. The lines above get handled differently from 4.0.4 to 4.0.5. It
>is hard to track if the comment is inside a class, because there is no parse
>error until the end of the file, and the code is not spit out like HTML (as
>in the example above) because it is compiling the file. I think this is a
>bug. We can clean up our code to fix it (and will), but
>
>Sincerely,
>
>Steven Roussey
>Network54.com
>http://network54.com/?pp=e
>
>
>--
>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 / NEWS php.ini-dist php.ini-optimized /ext/standard url_scanner.c url_scanner_ex.c url_scanner_ex.re /main main.c php_globals.h php_variables.c

[Andi Gutmans]

At 10:22 AM 4/5/2001 +0200, Sascha Schumann wrote:
>On Wed, 4 Apr 2001, Jani Taskinen wrote:
>
> > sniperWed Apr  4 13:46:27 2001 EDT
> >
> >   Modified files:
> > /php4 php.ini-dist php.ini-optimized NEWS
> > /php4/ext/standardurl_scanner.c url_scanner_ex.re 
> url_scanner_ex.c
> > /php4/mainmain.c php_globals.h php_variables.c
> >   Log:
> >   Added new configuration directives:
> >   arg_separator.input and arg_separator.output
>
> Am I the only one who thinks that breaking installations
> which use a different arg_separator is odd?  Now all those
> working installations have to be manually modified just to
> append ".output".

Considering the ambiguity I think it is the right thing to do. The default 
behavior will be backwards compatible and we can have a big caps news entry 
about it (for people who changed arg_separator). We could also keep 
arg_separator as an INI parameter in 4.0.5 and raise an error with a 
message on how to fix it (changing arg_separator to arg_separator.output).

Andi

Andi


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

Re: [PHP-DEV] Request for new feature: $HTTP_SESSION_VARS when register_globals = on

[Andi Gutmans]

Yes, what you're saying definitely makes sense and I think it should be fixed.

Andi

At 09:20 PM 4/5/2001 +0200, Carsten Gehling wrote:
>One of the IMHO stranger behaviors in PHP is what happens to the
>$HTTP_SESSION_VARS array when changing register_globals from off to on.
>
>If register_globals is set to on, you cannot access $HTTP_SESSION_VARS any
>longer. Instead you can get the values through implicit created variables or
>through the $GLOBALS array.
>
>Now compare this to $HTTP_GET_VARS and $HTTP_POST_VARS. Both of these arrays
>are available regardless of what register_globals is set to.
>
>Shouldn't it be the same for $HTTP_SESSION_VARS ?
>
>- Carsten
>
>
>
>--
>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] Hash Functions API

[Andi Gutmans]

At 01:40 AM 4/12/2001 -0400, Stig Sæther Bakken wrote:
>["Brian Foddy" <[EMAIL PROTECTED]>]
> > I've been looking everywhere for a good reference of how to read and
> > update arrays.  The Zend documentation
> > (www.zend.com/apidoc) has descriptions of how to create
> > an array, and how to add elements to it, but I can't find anything on how
> > to simply read the values of an array.
> >
> > Mostly I want to write two functions:
> > 1.  Accept a provided 2 dimensional array and loop through
> > every element, by primary index then an inner loop by the second index,
> > sequentially.  I need to extract from the array the two keys and the
> >value.  The keys will not be sequential, at least the primary.
> >
> > 2.  Build a 2-d array, basically the reverse of 1 above.  Build an array
> >  with specific primary and secondary indexes.  Again keys will not
> > be sequential.
> >
> > To make matters worse, I'd like the keys to be either integer or strings.
> >
> > I've looked through the zend_hash.h header, and a few functions look
> > likely (zend_hash_move_forward, zend_hash_get_current_key).
>
>Those are the ones you want, plus zend_hash_get_current_data.

Also check out the _ex() functions. They give you more features.
Andi


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

[PHP-DEV] Re: Bug in PHP-4.0.5RC6?

[Andi Gutmans]

Does this work for you on 4.0.4pl1?
Any idea when this broke?
Andi

At 12:24 AM 4/13/2001 +0200, Didi Rieder wrote:
>Hello,
>
>I have a problem with "popen" and "fgets" in php-4.0.5RC6 on Solaris 8 
>(Sparc):
>
>Script:
>
>$rc = '';
>$pipe = popen("/bin/ls -la /tmp", "r");
> while (($rc = fgets($pipe, 8192))) {
> print $rc;
> }
>pclose($pipe);
>?>
>
>It produces:
>total 290
>
>A normal commandline listing would produce:
>
>[root@sbox /root]# ls -la /tmp
>total 290
>drwxrwxrwt   9 sys  sys 1109 Apr 13 00:20 .
>drwxr-xr-x  24 root root 512 Apr  9 15:43 ..
>drwxrwxrwx   2 root root 179 Feb 25 15:30 .pcmcia
>drwx--   2 root other117 Apr  2 19:22 AOaWLY
>drwx--   2 root other117 Mar 28 13:11 gCaqL6
>-rw-r--r--   1 root other  19665 Apr 11 21:27 imp-sieve.tar.gz
>-rw-rw--w-   1 cyrusmail   25098 Apr 12 21:24 imp.log
>-rw---   1 root other  0 Mar 30 22:36 mpEeaWIz
>-rw---   1 root other  0 Mar 29 13:54 mpUZa4Po
>srwxrwxrwx   1 root other  0 Mar 28 16:36 mysql.sock
>drwxr-xr-x   3 root other248 Mar 23 20:57 new
>-rw-rw-r--   1 root sys 6496 Feb 25 15:29 ps_data
>-rw---   1 root other  0 Apr 12 19:41 session_mm.sem
>-rw-rw--w-   1 cyrusmail8644 Apr 12 00:16 sieve.log
>drwx--   2 root other181 Apr 13 00:04 ssh-YgP13837
>drwx--   2 root other181 Apr  7 10:46 ssh-ZPD12871
>drwx--   2 root other181 Apr  7 10:56 ssh-wza13793
>
>
>~regards
> Didi
>
>--
>
>Didi Rieder
>[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] always building cgi...

[Andi Gutmans]

I think having a CGI (command line) version of PHP built in any case is a 
very useful thing. I would just make it build with the same options as the 
rest. So if we build a non-threadsafe Apache 1.3.x module I would also 
build a non-threadsafe command line version (just in case the person feels 
like using it).  If you build a thread-safe version then we can build a 
thread-safe command line version.
All it really requires is compiling cgi_main.c with the same flags and 
linking it to the libphp4.la
I just think it's a useful thing to have. I wouldn't complicate this into 
allowing people to build both Apache & thttpd versions with the same "make" 
command. I think people are really interested in just having a command line 
& web server version.
Andi

At 02:58 PM 4/13/2001 +0300, Boian Bonev wrote:

> > > With some more minor restructuring, we can then let people build _all_
> > > sapi modules in one go if they like.
> > Without careful consideration, I would not say that it would
> > require only minor restructuring.  If we would implement that
> > change, it would have a direct effect upon the installation
> > procedure of PHP.  That is not a problem with online
> > documentation, but what about printed manuals and the dozens
> > of books on PHP?  I'd be very hesitant to change anything
> > here which would render those descriptions invalid.
>
>if a backwards compatible configure command line is kept valid why not? if
>the sapi module(s) to install becomes a list of --with-somesapi it would not
>break neighter descriptions nor saved built scripts.
>
> > On the implementation side, I'm not convinced of the
> > usefulness of such a change.  The way libphp4.la is built
> > directly depends upon the chosen SAPI module (thread-safety,
> > shared/static).  As of today, there are only a few possible
> > combinations.  From day-to-day experience, I have yet to see
> > an installation where web-servers run parallelly (and which
> > use PHP/require the same build options).
>
>there are two ways of building libphp4.la - thread safe and not thread safe.
>let us say libphp4.la and libphp4ts.la. the rest is just a linker option or
>am i missing something? i think the idea to separate the sapi stuff from the
>rest of php is not that bad - you build php once (or twice for TS) and then
>link to sapi modules at will.
>
>b.
>
>
>--
>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] always building cgi...

[Andi Gutmans]

Well I have been abroad and been reading Emails very slowly via 
international calls so I might have missed a few (no need for the sarcasm).
What I describe is the situation I would like to see. I will try and catch 
up will the zillions of Email I have and see why this can't be achieved.

Andi

At 04:01 PM 4/15/2001 +0200, Sascha Schumann wrote:
> > All it really requires is compiling cgi_main.c with the same flags and
> > linking it to the libphp4.la
>
> If you had read the emails, you would have noticed the
> problem behind that thought.
>
> - Sascha Experience IRCG
>   http://schumann.cx/http://schumann.cx/ircg


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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Andi Gutmans]

Wez,

I haven't had much time to go over it but it looks like it's definitely in 
the right direction. I've wanted to see something like this in PHP for a while.
Any chance you can write a small readme file or add some explanations to 
the .h file to give people like me a small overview of the abstraction so 
that it will be easier to start diving into the code?

Thanks,

Andi

At 06:24 PM 4/17/2001 +0100, Wez Furlong wrote:
>On 2001-04-17 17:20:34, "Zeev Suraski" <[EMAIL PROTECTED]> wrote:
> > How did you implement it?  The main problem with doing this until now was
> > that under Windows, it's pretty much impossible to get a FILE* from a
> > socket.  The right way to implement it would most probably be implementing
> > something similar to C++'s virtual classes, so I'm wondering whether you
> > did it that way...
>
>It's in CVS now - take a look at main/php_streams.h.
>
>It's a bit like implementing our own set of stdio functions and using 
>those rather than the ANSI ones; these call down into the ANSI stdio or 
>fds/sockets (or SSL sockets eventually) as appropriate.
>
>Casting into a FILE* just makes use of fdopen for sockets, or returns the 
>underlying FILE* if there is one.
>
>We can only pass back a FILE* for something really alien if we have 
>fopencookie.
>
>There's no real magic in it :-)
>
>If you can spot problems with this let me know!
>
>--Wez.
>
>
>--
>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 / TODO-4.1.txt

[Andi Gutmans]

At 11:55 AM 4/18/2001 +0100, Wez Furlong wrote:
>On 2001-04-17 21:08:15, "Andi Gutmans" <[EMAIL PROTECTED]> wrote:
> > Any chance you can write a small readme file or add some explanations to
> > the .h file to give people like me a small overview of the abstraction so
> > that it will be easier to start diving into the code?
>
>I've just commited README.STREAMS to the php4 root.

Great! I'll read it soon.
We should probably put it in php4/main or create a php4/doc and move docs 
there. The less we clutter the main directory the better.

Andi


-- 
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 / TODO-4.1.txt

[Andi Gutmans]

At 11:55 AM 4/18/2001 +0100, Wez Furlong wrote:
>On 2001-04-17 21:08:15, "Andi Gutmans" <[EMAIL PROTECTED]> wrote:
> > Any chance you can write a small readme file or add some explanations to
> > the .h file to give people like me a small overview of the abstraction so
> > that it will be easier to start diving into the code?
>
>I've just commited README.STREAMS to the php4 root.

I'm glad I asked you to write this document.
It's extremely helpful for getting a good and quick overview of the streams.
Great job and again, this is something I've wanted to see for a long time!

Andi


-- 
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 / TODO-4.1.txt

[Andi Gutmans]

At 06:53 PM 4/18/2001 -0400, Stig Sæther Bakken wrote:

>*BLAM*
>
>That's the sound of someone shooting himself in the foot.  The PEAR
>installer needs the XML extension. :-)

What do you mean? Has work started on this already?
I'm not quite sure what you mean by the PEAR installer but I think we 
should discuss the util we would need to list/fetch/build C extensions from 
the PEAR repository on php-dev@.
I think it's a waste of time to decide right now what to remove instead of 
trying to finalizing this utility. Once we see how well it works it'll be 
time to start thinking of what extensions to remove. I think it's just 
putting energy in the wrong place right now :)

Andi


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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Andi Gutmans]

At 03:33 AM 4/19/2001 +0300, Zeev Suraski wrote:
>Guys,
>
>Over the years, there's always been a tendency to think about things which 
>are 10 steps ahead.  It never worked, and I don't think it would work here 
>either.  Moreover, I don't see any advantage in discussing this now - on 
>the contrary - we really have no idea what we're talking about.  Whether 
>or not we separate modules *at all* will greatly depend on how good an 
>implementation we end up having.  How many of them we end up separating 
>will also depend on that.  Let's just wait with those discussions until 
>they're somehow connected with reality.
>
>Zeev

Scary... Didn't read this before :)

Andi


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

[PHP-DEV] Re: [PHP-CVS] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Andi Gutmans]

At 10:03 PM 4/18/2001 -0400, Stig Sæther Bakken wrote:
>["Sean R. Bright" <[EMAIL PROTECTED]>]
> > To continue a tangent... I don't like the idea of having the PEAR
> > fetching/installation mechanism written in PHP (already some base code in
> > PEAR to do this).  It seems to me that it forces the user to download/build
> > PHP and then download and rebuild PHP with any extensions that don't 
> come in
> > the base distribution.  Instead it should be a binary that can be compiled
> > before PHP is built, can download and configure any extensions 
> requested and
> > then build the resulting PHP binary.  We can also build in a dependency
> > mechanism where for example, someone chooses to install a PEAR module 
> (be it
> > PHP or C) and the required extensions would be downloaded as well.
> >
> > Just my $0.02
>
>I see your point, but personally I code 5 times faster in PHP than in
>C, and I want to get this done now, not next year. :-)
>
>When we're past the prototyping phase and stuff stabilizes, a C
>rewrite may be a good idea, but I don't think it is now.

Well you know the most permanent things are temporary things such as 
prototypes.
I also thought it would make much more sense to create something very small 
in C (maybe even Perl as it's installed on all systems) and use that.
I'm not really sure anymore what this installer you are talking about looks 
like. So I think it would be good to get a small update and have a 
discussion of what we need on php-dev@.

Thanks,

Andi


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

Re: [PHP-DEV] Re: [PHP-CVS] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Andi Gutmans]

At 09:16 PM 4/18/2001 -0700, Rasmus Lerdorf wrote:
> > >When we're past the prototyping phase and stuff stabilizes, a C
> > >rewrite may be a good idea, but I don't think it is now.
> >
> > Well you know the most permanent things are temporary things such as
> > prototypes.
> > I also thought it would make much more sense to create something very small
> > in C (maybe even Perl as it's installed on all systems) and use that.
> > I'm not really sure anymore what this installer you are talking about looks
> > like. So I think it would be good to get a small update and have a
> > discussion of what we need on php-dev@.
>
>I see no issue with writing a prototype in PHP.  The start of such a
>prototype is in cvs (pear/script/pear)
>
>And yes, using XML is pretty much a no-brainer here.  That will allow a
>lot of different nifty tools to access the package information.

For a start you don't have PHP installed on most systems. So PHP would need 
to compile itself and then fetch packages and recompile itself. Seems to me 
like the no-brainer isn't such a no-brainer.

Andi


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

Re: [PHP-DEV] Re: [PHP-CVS] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Andi Gutmans]

At 09:24 PM 4/18/2001 -0700, Rasmus Lerdorf wrote:
> > At 09:16 PM 4/18/2001 -0700, Rasmus Lerdorf wrote:
> > > > >When we're past the prototyping phase and stuff stabilizes, a C
> > > > >rewrite may be a good idea, but I don't think it is now.
> > > >
> > > > Well you know the most permanent things are temporary things such as
> > > > prototypes.
> > > > I also thought it would make much more sense to create something 
> very small
> > > > in C (maybe even Perl as it's installed on all systems) and use that.
> > > > I'm not really sure anymore what this installer you are talking 
> about looks
> > > > like. So I think it would be good to get a small update and have a
> > > > discussion of what we need on php-dev@.
> > >
> > >I see no issue with writing a prototype in PHP.  The start of such a
> > >prototype is in cvs (pear/script/pear)
> > >
> > >And yes, using XML is pretty much a no-brainer here.  That will allow a
> > >lot of different nifty tools to access the package information.
> >
> > For a start you don't have PHP installed on most systems. So PHP would need
> > to compile itself and then fetch packages and recompile itself. Seems to me
> > like the no-brainer isn't such a no-brainer.
>
>We need to somehow work out the functionality.  Once it is well-defined
>other clients will come, I am sure.  We can always provide a small
>statically linked installer program which includes a stripped down PHP
>binary and the appropriate Installer class.

Right but if we chose XML this makes it much harder to have C clients (even 
Perl because the module might not be installed). I don't think it will be 
such a complicated format for us to need XML here especially as it limits 
what clients will be created. I think it needs more thought. Having a 
prototype for the functionality is OK but not if you're talking about a 
prototype which sets the standard.


>If we were to write it in C we would most likely need to provide a
>statically linked binary anyway for the different platforms as not
>everyone will have access to a fully functioning development environment.

If they are compiling PHP and PHP extensions we can expect them to be able 
to compile an ANSI C program.


>Despite the pervasiveness of Perl, chances are high that certain Perl
>modules would be missing and then someone has to go looking for Perl
>modules to install PHP packages..  Ouch!

You can do this kind of stuff with the Vanilla Perl and don't need extensions.

Andi


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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Andi Gutmans]

At 08:03 AM 4/19/2001 -0400, Stig Sæther Bakken wrote:
>[Andi Gutmans <[EMAIL PROTECTED]>]
> > At 06:53 PM 4/18/2001 -0400, Stig Sæther Bakken wrote:
> >
> > >*BLAM*
> > >
> > >That's the sound of someone shooting himself in the foot.  The PEAR
> > >installer needs the XML extension. :-)
> >
> > What do you mean? Has work started on this already?
> > I'm not quite sure what you mean by the PEAR installer but I think we
> > should discuss the util we would need to list/fetch/build C extensions
> > from the PEAR repository on php-dev@.
> > I think it's a waste of time to decide right now what to remove
> > instead of trying to finalizing this utility. Once we see how well it
> > works it'll be time to start thinking of what extensions to remove. I
> > think it's just putting energy in the wrong place right now :)
>
>You don't read php-cvs anymore do you Andi? :-)

I do but I'm senile :)


>If you configure the CGI and do "make install", you'll have a
>command-line utility written in PHP called "pear" that can do two
>things: make a package tarball, and install a tarball.  It currently
>only support "pure PHP" packages.  How to test it:
>
>$ cvs co pear/HTTP
>$ cd pear/HTTP
>$ pear package package.xml
>(this will give you a file called HTTP-1.0.tgz)
>$ pear install HTTP-1.0.tgz

OK I definitely missed that one.

>There's a lot of stuff missing from the installer still, but that'll
>be added in time.  It is also UNIX-only right now.  Since I'm not a
>Windows user myself, I totally depend on the help of some Windows
>people to make it work in Windows.
>
>The reason I joined the "what extensions to keep" discussion is that I
>think it (the discussion) is going to take some time. :-)

Yeah but I just thought it'd be better to focus people's energy on getting 
it to work :)

Andi


--
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] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Andi Gutmans]

At 08:13 AM 4/19/2001 -0400, Stig Sæther Bakken wrote:
>[Andi Gutmans <[EMAIL PROTECTED]>]
> >
> > Right but if we chose XML this makes it much harder to have C clients
> > (even Perl because the module might not be installed). I don't think
> 
>
>Over my dead body.  Take a look at all the magazines reviewing which
>web development tools to use.  Most of them end up with PHP because it
>fits their job.  Imagine all the fun authors of such articles can have
>it PHP requires Perl to install the stuff you need.
>
> > it will be such a complicated format for us to need XML here
> > especially as it limits what clients will be created. I think it needs
> > more thought. Having a prototype for the functionality is OK but not
> > if you're talking about a prototype which sets the standard.
>
>XML is a commodity today.  Just take a look at what the industry out
>there is using.
>
> > >If we were to write it in C we would most likely need to provide a
> > >statically linked binary anyway for the different platforms as not
> > >everyone will have access to a fully functioning development environment.
> >
> > If they are compiling PHP and PHP extensions we can expect them to be
> > able to compile an ANSI C program.
> >
> >
> > >Despite the pervasiveness of Perl, chances are high that certain Perl
> > >modules would be missing and then someone has to go looking for Perl
> > >modules to install PHP packages..  Ouch!
> >
> > You can do this kind of stuff with the Vanilla Perl and don't need
> > extensions.
>
>To be quite blunt, I don't have the time to implement this in C.
>
>I've tried to get people involved in the strategy for PEAR for months
>and months.  It's typical that nobody reacts until after
>implementation has started though.  I want to get this system up and
>running sooner rather than later, so I'm willing to make something
>that we throw away and reimplement rather than to not have something
>for one more year.

I think you are right.
BTW, how are you planning on making it as transparent as possible for a 
user who downloads PHP and wants to compile it with PEAR C-extensions such 
as XML, MySQL & Oracle (these are just examples, it doesn't reflect my 
opinion if these should stay in or out of the php tree itself)?

Andi


--
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] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Andi Gutmans]

At 09:05 AM 4/19/2001 +0300, Alexander Bokovoy wrote:
>On Thu, Apr 19, 2001 at 07:21:32AM +0200, Andi Gutmans wrote:
> > At 09:16 PM 4/18/2001 -0700, Rasmus Lerdorf wrote:
> > > > >When we're past the prototyping phase and stuff stabilizes, a C
> > > > >rewrite may be a good idea, but I don't think it is now.
> > > >
> > > > Well you know the most permanent things are temporary things such as
> > > > prototypes.
> > > > I also thought it would make much more sense to create something 
> very small
> > > > in C (maybe even Perl as it's installed on all systems) and use that.
> > > > I'm not really sure anymore what this installer you are talking 
> about looks
> > > > like. So I think it would be good to get a small update and have a
> > > > discussion of what we need on php-dev@.
> > >
> > >I see no issue with writing a prototype in PHP.  The start of such a
> > >prototype is in cvs (pear/script/pear)
> > >
> > >And yes, using XML is pretty much a no-brainer here.  That will allow a
> > >lot of different nifty tools to access the package information.
> >
> > For a start you don't have PHP installed on most systems. So PHP would 
> need
> > to compile itself and then fetch packages and recompile itself. Seems 
> to me
> > like the no-brainer isn't such a no-brainer.
>Seems that you're forgetting main point of PEAR: you don't need to
>recompile PHP itself when adding some module via PEAR because more
>suitable method exists -- self contained extensions -- which works via
>PEAR right now. Of course, there is small number of extensions from /ext
>which could be compiled in this mode out-of-the-box right now (mostly
>because building environment in PEAR still unreliable), but it exists.

I still think that a large majority of people will want to grab the 
C-extensions and compile them statically into PHP, i.e. putting them in 
ext/, ./buildconf, ./configure ...

Andi


-- 
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: [PHP-QA] RC7 is out

[Andi Gutmans]

At 02:59 PM 4/20/2001 -0700, Andrew Sitnikov wrote:
>Hello Zeev,
>
>neljapäev, 19.04.2001, you wrote:
>
>
>ZS> I rolled RC7 - if there are no surprises (there'd better not be! :), it
>ZS> can finally go out early next week.
>
>ZS> Zeev
>
>Where i can get it ?

http://www.php.net/distributions/php-4.0.5RC7.tar.gz

Andi


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

Re: [PHP-DEV] unix install paths changed

[Andi Gutmans]

At 09:59 AM 4/23/2001 -0700, Frank M. Kromann wrote:
>These have to be defined on Win32 as well. In order to compile I can just 
>put some default definitions in config.w32.h.
>
>I'm getting another error though:
>
>D:\php\php4\main\php_ini.c(190) : error C2065: 'llist_dtor_func_t' : 
>undeclared identifier
>
>There is llist_dtor_func_t defined ?

This is due to a patch of mine to the Zend CVS. You forgot to update your 
Zend checkout.

Andi


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

Re: [PHP-DEV] is_link() behavior

[Andi Gutmans]

It definitely seems as if the logic in the code (filestat.c) is kind of 
screwed up.
If no one has time to look at it I can try and take a look at it later on.

Andi

At 01:35 AM 4/24/2001 -0500, J. Jones wrote:
>This was originally posted to php-general, but for some reason I believe
>it may belong here.  I apologize if I'm wrong.
>
>
>Forgive me for my ignorance, but I've noticed some unwanted behavior
>(IMO, at least) with the is_link() function.  Given the simple code..
>
> if ( is_link ("/tmp/this_is_a_symlink") )
> print ("Success\n");
>
>and the file..
> lrwxrwxrwx 1 root root 5 Apr 23 21:19 /tmp/this_is_a_symlink -> /bin/
>the above obviously prints 'Success\n'.
>
>However, if I BREAK the symlink, with something like the following..
> lrwxrwxrwx 1 root root 4 Apr 23 21:21 /tmp/this_is_a_symlink -> foo
>the script fails with..
>
>Warning: stat failed for /tmp/this_is_a_symlink (errno=2 - No such file or
>directory) in ./test.php on line 3.
>
>The file /tmp/this_is_a_symlink is still a symlink, so it seems to me that
>the is_link() function should still return true, whether or not the symlink's
>target exists.  Is there perhaps a function I have yet to discover that
>provides that behavior, without verifying the link's target?
>
>I ask this because much of linux's /proc contains (intentionally) broken
>symlink's and is_link()'s behavior is making the scouring of /proc
>difficult on me.  ;)
>
>Thanks for any input..
>J. Jones
>
>P.S.  The script ran as root, so filesystem permissions aren't the issue.
>
>--
>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] 4.0.5: Merge Request

[Andi Gutmans]

At 03:59 PM 4/24/2001 +0300, Zeev Suraski wrote:
>A reproducible crash bug in a mainstream module is a show stopper IMHO...

I think you mean in a mainstream module and in a situation which has a high 
chance of happening.
Crash bugs which are 1 in a million don't necessarily need to be show stoppers.

Andi


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

Re: [PHP-DEV] 4.0.5: Merge Request

[Andi Gutmans]

Well you want me to merge the foreach() fix then? I don't because I prefer 
it being tested for a while so that we don't have a pl1.
I don't think we fix all crash bugs every release. Mainly buffer overflows 
are dangerous. Not double free()'s or de-referencing NULL pointers. But of 
course, a lot of crashes are potentially dangerous but we would never have 
any releases if we'd make sure that there's no chance PHP can crash, ever.

Andi

At 04:12 PM 4/24/2001 +0300, you wrote:
>Not necessarily;  Crash bugs can very often lead to security issues.  Of 
>course, it's a clearer cut if it's in a situation which is very likely to 
>happen.
>
>Zeev
>
>
>At 17:09 24/4/2001, Andi Gutmans wrote:
>>At 03:59 PM 4/24/2001 +0300, Zeev Suraski wrote:
>>>A reproducible crash bug in a mainstream module is a show stopper IMHO...
>>
>>I think you mean in a mainstream module and in a situation which has a 
>>high chance of happening.
>>Crash bugs which are 1 in a million don't necessarily need to be show 
>>stoppers.
>>
>>Andi
>
>--
>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] Fwd: [PHP-CVS] cvs: php4(PHP_4_0_5) /ext/standard array.c

[Andi Gutmans]

Looks like it got merged before RC7.
Can you check if your source includes this fix?

>From: "Andrei Zmievski" <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Date: Mon, 02 Apr 2001 16:12:07 -
>Subject: [PHP-CVS] cvs: php4(PHP_4_0_5) /ext/standard array.c
>
>andrei  Mon Apr  2 09:12:07 2001 EDT
>
>   Modified files:  (Branch: PHP_4_0_5)
> /php4/ext/standard  array.c
>   Log:
>   MFH
>
>
>Index: php4/ext/standard/array.c
>diff -u php4/ext/standard/array.c:1.101 php4/ext/standard/array.c:1.101.2.1
>--- php4/ext/standard/array.c:1.101 Mon Mar 12 02:14:00 2001
>+++ php4/ext/standard/array.c   Mon Apr  2 09:12:06 2001
>@@ -21,7 +21,7 @@
> +--+
>  */
>
>-/* $Id: array.c,v 1.101 2001/03/12 10:14:00 stas Exp $ */
>+/* $Id: array.c,v 1.101.2.1 2001/04/02 16:12:06 andrei Exp $ */
>
>  #include "php.h"
>  #include "php_ini.h"
>@@ -2195,7 +2195,7 @@
> switch (zend_hash_get_current_key_ex(target_hash, 
> &string_key, &str_key_len, &num_key, 1, &pos)) {
> case HASH_KEY_IS_STRING:
> Z_STRVAL_P(data) = string_key;
>-   Z_STRLEN_P(data) = str_key_len;
>+   Z_STRLEN_P(data) = str_key_len-1;
> Z_TYPE_P(data) = IS_STRING;
> break;
> case HASH_KEY_IS_LONG:
>
>
>
>--
>PHP CVS 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 
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.5 RC7 and TRANS_SID under Win32

[Andi Gutmans]

Did this work in the past? If so, any idea when it stopped working?

Andi

At 10:13 AM 4/24/2001 -0400, Matt White wrote:
>Hello...
>
>I'm banging around on PHP 4.0.5 RC7 Win32 (Apache module), and I'm having 
>great difficultly getting the TRANS_SID feature to work. I have one web 
>application which depends heavily on it, and it's unusable under 4.0.5RC7.
>
>Has anyone else been experiencing this difficultly?
>
>- Matt
>
>
>--
>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] 4.0.5: Merge Request

[Andi Gutmans]

At 02:24 AM 4/25/2001 +0300, Zeev Suraski wrote:
>While I'd say Jani's letter was slightly over emotional ;), he does have a 
>point.
>I think that taking a stop to look closely at the bugs database would be a 
>good thing, and the turn of a new version is a good time to do 
>it.  Deciding 4.0.6 won't include any significant new features, and that 
>we'll start its release process after a bugs-database-cleaning period 
>sounds like a good idea to me.

Well I was saying exactly what Jani is saying. That if you want a bug free 
minor version then you have to be aware of all the existing crash bugs in 
the bugs database and not live in the illusion that this last 4.0.5 crash 
bug fix creates now a stable version. I don't think every crash bug can be 
a show stopper. Our releases would slow down to a halt.
I don't think it's enough to decide that 4.0.6 won't have additional 
features (also because it has enough additional features already which are 
enough for another minor version), but the developers need to actually go 
through the bugs database and work on those crash bugs. It's not that easy 
to get everyone to work on them.

Anyway, I think it's a good idea to decide on a one to two week intensive 
period where no features are added and all developers work hard on closing 
crash bugs and other serious bugs. The problem is that there will be lots 
of developers who will want their very important patches going into 4.0.6 
and quite a few who won't be bothered to do the tough job. I'm not sure 
this would work.
Andi


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

Re: [PHP-DEV] is_link() behavior

[Andi Gutmans]

Hi,

I just commited a patch which also cleaned up some other stuff (although it 
could still use some fixing up).
Please check the latest CVS to see if it works now.
Also can you please check the lstat() command? I think it has the same 
problem (I didn't fix it because I want to be sure) and I think filetype() 
might also not work correctly on links which aren't pointing to anything 
(at least not give all the right information).

Andi

At 04:51 PM 4/24/2001 -0500, J. Jones wrote:
>On Tue, Apr 24, 2001 at 10:50:36AM +0200, Andi Gutmans wrote:
> > It definitely seems as if the logic in the code (filestat.c) is kind of
> > screwed up.
> > If no one has time to look at it I can try and take a look at it later on.
> >
> > Andi
> >
> > At 01:35 AM 4/24/2001 -0500, J. Jones wrote:
> > >Forgive me for my ignorance, but I've noticed some unwanted behavior
> > >(IMO, at least) with the is_link() function.  Given the simple code..
> > >
> > > if ( is_link ("/tmp/this_is_a_symlink") )
> > > print ("Success\n");
> > >
> > >and the file..
> > > lrwxrwxrwx 1 root root 5 Apr 23 21:19 /tmp/this_is_a_symlink 
> -> /bin/
> > >the above obviously prints 'Success\n'.
> > >
> > >However, if I BREAK the symlink, with something like the following..
> > > lrwxrwxrwx 1 root root 4 Apr 23 21:21 /tmp/this_is_a_symlink 
> -> foo
> > >the script fails with..
> > >
> > >Warning: stat failed for /tmp/this_is_a_symlink (errno=2 - No such file or
> > >directory) in ./test.php on line 3.
> > >
> > >The file /tmp/this_is_a_symlink is still a symlink, so it seems to me that
> > >the is_link() function should still return true, whether or not the 
> symlink's
> > >target exists.  Is there perhaps a function I have yet to discover that
> > >provides that behavior, without verifying the link's target?
> > >
>
>I grew impatient, and devised a simple (2 line) workaround in filestat.c.
>Basically it just required NOT doing a stat() if is_link() was calling
>php_stat().  This probably isn't 'the' fix, but it works great for me, and
>I know you guys are pretty busy.  Attached is my diff against
>php-4.0.4pl1's ext/standard/filestat.c.
>
>Thanks for the great language! Keep it up!
>
>J. Jones


-- 
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] 4.0.5: Merge Request

[Andi Gutmans]

At 10:35 PM 4/24/2001 -0700, Rasmus Lerdorf wrote:
> > At 02:24 AM 4/25/2001 +0300, Zeev Suraski wrote:
> > >While I'd say Jani's letter was slightly over emotional ;), he does have a
> > >point.
> > >I think that taking a stop to look closely at the bugs database would be a
> > >good thing, and the turn of a new version is a good time to do
> > >it.  Deciding 4.0.6 won't include any significant new features, and that
> > >we'll start its release process after a bugs-database-cleaning period
> > >sounds like a good idea to me.
> >
> > Well I was saying exactly what Jani is saying. That if you want a bug free
> > minor version then you have to be aware of all the existing crash bugs in
> > the bugs database and not live in the illusion that this last 4.0.5 crash
> > bug fix creates now a stable version. I don't think every crash bug can be
> > a show stopper. Our releases would slow down to a halt.
>
>Nobody is talking about such an illusion.  Let's not lose track of what
>caused this ruckus.  A crash bug was found and fixed in a mainstream
>extension.  It was just before a release.  So the release was put off for
>a couple of days to get this fix in.  I see absolutely nothing wrong with
>this.

Neither do I.


>Of course there are still bugs.  And yes there are still serious bugs
>lurking.  But none we have a known and tested fix for.

Yes but for example the crash bug I fixed in foreach(). I don't think it 
was a showstopper. It ended up slipping in because there was another RC 
anyway (and it was a one liner) but what I meant is that not all crash bugs 
are show stoppers.


> > Anyway, I think it's a good idea to decide on a one to two week intensive
> > period where no features are added and all developers work hard on closing
> > crash bugs and other serious bugs. The problem is that there will be lots
> > of developers who will want their very important patches going into 4.0.6
> > and quite a few who won't be bothered to do the tough job. I'm not sure
> > this would work.
>
>This will definitely not work as "all developers" are at very different
>stages of development.  Some extensions are very young and evolving
>quickly right now.  Telling a developer with such an extension to stop
>developing the extension and only fix bugs doesn't make much sense.


I disagree. I don't think having developers take off a couple of days from 
their "stage of development" and help the greater PHP cause is a big deal. 
After all it is these developers that can help fix bugs, and well what can 
we do, bugs aren't necessarily fixed by their authors.
It's much more fun coding and writing your own extension, and it's a good 
thing, but it doesn't mean you can't do some of the dirty work for a couple 
of days. That suggestion to look at the Debian model is a good idea IMO.


>The realistic way to do this, and the way I thought we had agreed on, is
>to create a release branch at some semi-stable point and not add new
>features to it but focus on fixing the most serious bugs in it.  And yes,
>I agree that it would be good if we could get more developers to focus on
>the release branch and devote more cycles to tracking down issues in the
>release branch, but here is where I would like the QA team or someone to
>step up and create a list of issues (likely just a list of bug id numbers)
>that they deem to be significant issues with the release branch.  It
>should not be the QA team's job to track down developers and try to
>convince them to fix bugs.
>
>eg.
>
>Release branch 4.0.87
>
>   Showstoppers: #20457, #24099
>   Serious: #24, #354354, #546543
>   Moderate: #535436, #45326543, #5443543
>
>Developers like finite-looking lists like this.  They can see an end to
>the work.  Fix 5 bugs and we are good to go for the release.  Obviously
>there will still be bugs, but at least this would be an organized approach
>to it.

Having a better defined/reproduced list of bugs is a must and if the QA 
team can do that PHP will definitely benefit from it. However, today when 
they ask people to fix bugs they are often not fixed and I don't even think 
that they are necessarily looked at. That is why a defined "everyone join 
forces to kill the bugs" period would be a good thing. And whoever doesn't 
help isn't allowed to hack on his extension anymore (Just kidding :).

Andi


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

Re: [PHP-DEV] is_link() behavior

[Andi Gutmans]

I commited another fix.
is_link() should work correctly now. If things have improved and you have 
problems with lstat() and filetype() (which I think there's a good chance 
that they are screwed up) let me know.
Thanks,
Andi

At 12:43 AM 4/25/2001 -0500, J. Jones wrote:
>On Wed, Apr 25, 2001 at 07:22:03AM +0200, Andi Gutmans wrote:
> > Hi,
> >
> > I just commited a patch which also cleaned up some other stuff 
> (although it
> > could still use some fixing up).
> > Please check the latest CVS to see if it works now.
> > Also can you please check the lstat() command? I think it has the same
> > problem (I didn't fix it because I want to be sure) and I think filetype()
> > might also not work correctly on links which aren't pointing to anything
> > (at least not give all the right information).
> >
> > Andi
> >
>
>Hey.. I pulled just the filestat.c out of CVS into php-4.0.4pl1..
>hopefully that isn't the issue (I recieved no warnings during the compile,
>and nothing really seemed to have changed much in the ext/standard/
>directory).
>
>--code:
>function link_func_test ($file)
>{
>  if ( is_link ($file)) { print ("is_link passed\n"); }
>  else { print ("is_link failed\n"); }
>
>  if (($temp_filetype = filetype ($file))) { print ("filetype passed:
>$temp_filetype\n"); }
>  else { print ("filetype failed\n"); }
>
>  if (($temp_lstat = lstat ($file))) { print ("lstat passed:\n\n");
>print_r ($temp_lstat); }
>  else { print ("lstat failed\n"); }
>}
>
>$file = '/tmp/test-link-func';
>// This was if (file_exists ($file)), but it's borked too! ;)
>@ unlink ($file);
>
>if (symlink ('/bin/false', $file)) { link_func_test ($file); }
>else { print ("Good symlink failed\n"); }
>
>@ unlink ($file);
>
>if (symlink ('/this/file/does/not/exist', $file)) { link_func_test ($file); }
>else { print ("Bad symlink failed\n"); }
>--End
>
>
>--output:
>:(00:36am ~/php): ./fs-test.php
>is_link passed
>filetype passed:  link
>lstat passed:
>
>Array
>(
> [0] => 770
> [1] => 1273
> [2] => 41471
> [3] => 1
> [4] => 0
> [5] => 0
> [6] => 0
> [7] => 10
> [8] => 988177003
> [9] => 988177003
> [10] => 988177003
> [11] => 4096
> [12] => 1
>)
>
>Warning: lstat failed for (null) (errno=14 - Bad address) in ./fs-test.php
>on line 5
>is_link failed
>
>Warning: stat failed for /tmp/test-link-func (errno=2 - No such file or
>directory) in ./fs-test.php on line 8
>filetype failed
>
>Warning: stat failed for /tmp/test-link-func (errno=2 - No such file or
>directory) in ./fs-test.php on line 11
>lstat failed
>--end
>
>If there are other changes to the tree which may be affecting this I will
>grab the full CVS tree and try again.  Feel free to send me any patches
>directly for testing.
>
>Thanks!
>J. Jones


-- 
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] is_link() behavior

[Andi Gutmans]

The readlink() function? You mean the is_link() function no?
The readlink() function is something completely different.
Can you also try those other two functions? lstat() and filetype()?
Andi

At 12:48 AM 4/25/2001 -0500, J. Jones wrote:
>Oh.. the readlink () function works fine in both instances..
>
>readlink passed:  /bin/false
>readlink passed:  /this/file/does/not/exist


-- 
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.5: Merge Request

[Andi Gutmans]

At 11:04 PM 4/24/2001 -0700, Rasmus Lerdorf wrote:
> > Having a better defined/reproduced list of bugs is a must and if the QA
> > team can do that PHP will definitely benefit from it. However, today when
> > they ask people to fix bugs they are often not fixed and I don't even think
> > that they are necessarily looked at. That is why a defined "everyone join
> > forces to kill the bugs" period would be a good thing. And whoever doesn't
> > help isn't allowed to hack on his extension anymore (Just kidding :).
>
>Yes, but that is my point. They should not be asking people to fix bugs.
>They should simply be identifying and prioritizing the bugs.  As a group
>we need to fix the bugs.  Jani is complaining that they are ignored, so we
>need to change the atmosphere and remove that aspect from their duties.
>We are not going to change the way developers do their day-to-day jobs by
>much.  But by changing the approach to one that is centered around an
>itemized list of issues I think we will completely change how things work.
>Imagine if there is only 1 criticl bug left on the list and it is in a
>piece of code you wrote?  Everyone sees this list and everyone can see
>that as soon as this bug is fixed the release can go out.  That will
>motivate a developer into holding off on playing with cool new features
>and taking a look at the bug.
>
>The question right now is how to best implement this.  Do we add something
>to the bug database to flag bugs in some manner and have a release
>candidate summary page?
>
>Or do we separate it out of the bug database and maintain the list
>manually?

For the QA guys it might be nice to be able to flag certain bugs in the bug 
database and then automatically create a summary page which could be sent 
to php-dev. However, I think it would take too much time to get started. 
Maybe just manually creating a list with a one line description of bug #, 
where the bug is and a short short summary would be best. This could be 
sent to php-dev.


>I think this is something for the QA guys to bite into and answer if they
>agree that this sort of approach would improve their lives and make them
>less grumpy.

And the hackers will have to bite into the QA report because if they don't, 
then we get nowhere.

Andi


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

Re: [PHP-DEV] is_link() behavior

[Andi Gutmans]

At 01:05 AM 4/25/2001 -0500, J. Jones wrote:
>On Wed, Apr 25, 2001 at 08:56:47AM +0200, Andi Gutmans wrote:
> > I commited another fix.
> > is_link() should work correctly now. If things have improved and you have
> > problems with lstat() and filetype() (which I think there's a good chance
> > that they are screwed up) let me know.
> > Thanks,
> > Andi
>
>--new output
>:(01:02am ~/php): ./fs-test.php
>is_link passed
>readlink passed:  /bin/false
>filetype passed:  link
>lstat passed:
>
>Array
>(
> [0] => 770
> [1] => 749
> [2] => 41471
> [3] => 1
> [4] => 0
> [5] => 0
> [6] => 0
> [7] => 10
> [8] => 988178527
> [9] => 988178527
> [10] => 988178527
> [11] => 4096
> [12] => 1
>)
>is_link passed
>readlink passed:  /this/file/does/not/exist
>
>Warning: stat failed for /tmp/test-link-func (errno=2 - No such file or
>directory) in ./fs-test.php on line 11
>filetype failed
>
>Warning: stat failed for /tmp/test-link-func (errno=2 - No such file or
>directory) in ./fs-test.php on line 14
>lstat failed
>--end
>
>That's good enough for me.. is_link() and readlink() (what more do I
>really need for links?) both work perfect.

Do those last warnings mean that filetype() and lstat() don't work as I 
mentioned?


>One thing.. is /main/fopen-wrappers.h renamed to tree>/main/fopen_wrappers.h in CVS, or is that a typo? ;)

Renamed :)

Andi


-- 
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] is_link() behavior

[Andi Gutmans]

At 01:19 AM 4/25/2001 -0500, J. Jones wrote:
>On Wed, Apr 25, 2001 at 01:05:00AM -0500, J. Jones wrote:
> > On Wed, Apr 25, 2001 at 08:56:47AM +0200, Andi Gutmans wrote:
> > > I commited another fix.
> > > is_link() should work correctly now. If things have improved and you 
> have
> > > problems with lstat() and filetype() (which I think there's a good 
> chance
> > > that they are screwed up) let me know.
> > > Thanks,
> > > Andi
> >
> > --new output
> > :(01:02am ~/php): ./fs-test.php
> > is_link passed
> > readlink passed:  /bin/false
> > filetype passed:  link
> > lstat passed:
> >
> > Array
> > (
> > [0] => 770
> > [1] => 749
> > [2] => 41471
> > [3] => 1
> > [4] => 0
> > [5] => 0
> > [6] => 0
> > [7] => 10
> > [8] => 988178527
> > [9] => 988178527
> > [10] => 988178527
> > [11] => 4096
> > [12] => 1
> > )
> > is_link passed
> > readlink passed:  /this/file/does/not/exist
> >
> > Warning: stat failed for /tmp/test-link-func (errno=2 - No such file or
> > directory) in ./fs-test.php on line 11
> > filetype failed
> >
> > Warning: stat failed for /tmp/test-link-func (errno=2 - No such file or
> > directory) in ./fs-test.php on line 14
> > lstat failed
> > --end
> >
>
>Ok.. is_link() and readlink() (I realize this is in a separate section,
>but I still use it as opposed to lstat() to get the link's target) are the 
>only
>two functions that work on broken symlinks.
>
>filetype(), lstat(), and file_exists() all fail (the latter probably 
>should, eh?).
>
>I assume all the file() functions will fail also, since they are
>based on lstat() or stat().

OK. I commited one more patch which should fix filetype() and lstat(). I'd 
appreciate it if you can take a minute and just make sure they work now and 
that I didn't cause any problems with the fixed is_link().
It's not my code so that's why I'm messing with it slowly. It had some 
dependencies inside the code and I wanted to make sure I keep it consistent.

Andi


-- 
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] is_link() behavior

[Andi Gutmans]

At 01:46 AM 4/25/2001 -0500, J. Jones wrote:
>On Wed, Apr 25, 2001 at 09:33:47AM +0200, Andi Gutmans wrote:
> > OK. I commited one more patch which should fix filetype() and lstat(). I'd
> > appreciate it if you can take a minute and just make sure they work now 
> and
> > that I didn't cause any problems with the fixed is_link().
> > It's not my code so that's why I'm messing with it slowly. It had some
> > dependencies inside the code and I wanted to make sure I keep it 
> consistent.
> >
> > Andi
> >
>
>Looks perfect.. lstat() and filetype() both work fine on the broken
>symlink.. as does is_link().  I'd call it fixed.  ;)

Great!


>file_exists() still 'fails' on a broken symlink, but perhaps it should.
>That could get a little on the philosophical side.

Yes this is indeed a philosophical question and according to the PHP manual 
it is unclear.
I don't really care either way. It's probably best the way it is now.


>Thanks alot for the quick fix!

You're welcome.

Andi


-- 
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, Xerces, Xalan

[Andi Gutmans]

At 06:14 PM 4/25/2001 +0200, Jascha Wetzel wrote:
>Greetings,
>
>i just implementet php_xalan and it kind of works but we're still having
>problems combining it with php-4.0.4pl1.
>Strange things happen when php uses libxalan and libxerces. After everything
>worked fine, the xslt sheet has been processed correctly and the module and
>the libs have been unloaded, php segfaults for some yet unknown reason.
>
>Maybe someone who is more into php and/or libxalan/xerces interna could help
>?
>
>When i get to it I'll put up a page with the extension for you to experiment
>with.

Is your PHP extension a simple wrapper of those libaries or is it a 
relatively complicated extension?
Have you managed to get a backtrace of the core dump in order to see where 
the problem is? (Corruption, freeing memory twice in the engine, and so on...)

Andi


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

Re: [PHP-DEV] function table

[Andi Gutmans]

At 02:16 PM 4/26/2001 -0400, David Croft wrote:

>Hello, I'm implementing an extension that allows user callbacks.
>
>The Zend API document suggests using the Compiler globals to access the
>function table. However I see the XML extension is using Executor globals.

During execution the correct table to use is the executor globals one, 
i.e., EG(function_table).

Andi


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

Re: [PHP-DEV] Fw: [PHP-DOC] cfunction?

[Andi Gutmans]

At 09:41 PM 4/26/2001 +0200, Hojtsy Gabor wrote:
> > > This is a question for the php-dev people too.
> > > What are the other hidden features not documented
> > > like this?
> >
> > Check the code.  This is simply a legacy feature there only for backward
> > compatibility and should not be documented as we don't want people writing
> > new scripts that use cfunction.
>
>Then why it is used in some scripts in the test dir
>in the distribution?

It shouldn't be. I'll fix those.

Andi


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

Re: [PHP-DEV] 4.0.5: Merge Request

[Andi Gutmans]

At 12:11 AM 4/26/2001 -0400, Sterling Hughes wrote:
>I'll agree that the inverse of the above is true ;)))
>
>But if you look at it over time, it averages out, making the net
>effect equal 0.
>
>anyway, I think we agree on the math, we just disagree on whether the
>short term affect is worth it.
>
>regardless of the outcome, I'm fine though, I think that soon enough
>the releases (because of there nature) will become a feature freeze (as
>more features get added, there are less features that need to be added,
>plus the core is getting smaller soon, so the net effect will be more bug
>fix releases and less feature releases)...

It's psychological and a state of mind thing. If all developers know that 
for the next few days they shouldn't concentrate on adding new 
functionality but should help out the project by trying to fix bugs you'll 
end up having more bugs fixed.
I think usually developers prefer to work on new functionality and won't 
help with other bugs too much. If there is a call for this and some time 
frame trying to get everyone to work together that could make a difference 
(and respect to the guy who fixes the most amount of bugs ;)
By the way, it's not the end of the world if someone developers code on his 
machine at home and only commits it a few days later. You're not forcing 
him to stop development because he can still do it at home but at least you 
get the state of mind across and I think a lot of developers will join in.
Andi
Andi


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

Re: [PHP-DEV] Fw: [PHP-DOC] cfunction?

[Andi Gutmans]

At 12:51 PM 4/26/2001 -0700, Rasmus Lerdorf wrote:
> > At 09:41 PM 4/26/2001 +0200, Hojtsy Gabor wrote:
> > > > > This is a question for the php-dev people too.
> > > > > What are the other hidden features not documented
> > > > > like this?
> > > >
> > > > Check the code.  This is simply a legacy feature there only for 
> backward
> > > > compatibility and should not be documented as we don't want people 
> writing
> > > > new scripts that use cfunction.
> > >
> > >Then why it is used in some scripts in the test dir
> > >in the distribution?
> >
> > It shouldn't be. I'll fix those.
>
>Leave one, at least.  We want to know if this breaks.  At some point we
>will want to remove the feature from php, and then we can remove the test
>case.  But let's not remove testcases without removing the feature.  The
>test scripts are not meant as examples for users.

It won't break and if it does, all the better :)
As you see people do take example from the test cases if they are meant to 
be testcases or not.
I think for 4.1 we should nuke cfunction and possible also old_function. 
Don't forget that cfunction had a very very short live-time in the beta's 
of PHP 3. We made the function<->old_function switch pretty early.

Andi


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

Re: [PHP-DEV] Fw: [PHP-DOC] cfunction?

[Andi Gutmans]

At 01:28 PM 4/26/2001 -0700, Rasmus Lerdorf wrote:
> > >Leave one, at least.  We want to know if this breaks.  At some point we
> > >will want to remove the feature from php, and then we can remove the test
> > >case.  But let's not remove testcases without removing the feature.  The
> > >test scripts are not meant as examples for users.
> >
> > It won't break and if it does, all the better :)
> > As you see people do take example from the test cases if they are meant to
> > be testcases or not.
>
>Yes, but the thing is there because there are scripts that use it.  If we
>break it, then these scripts will break.  Therefore a test case should
>remain so we don't break it.  If you are worried about the testcase
>setting a bad example, stick a comment in there.  You don't remove test
>cases for features just because you don't like them.  If it is part of the
>language, it needs to be part of the regression testing.

Check zend_language_scanner.l for cfunction and you'll see why there is 
about a zillion times more chances that someone will discover cfunction 
from the test scripts then there is for cfunction to break without regular 
functions breaking too. So I think we can take our chances on this one.
Come on, it's really bullshit and we should have nuked cfunction a while ago.
If you really feel strongly about it then go ahead and put one back 
although I think it's OK the way it is now.

Andi


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

Re: [PHP-DEV] cfunction / old_function

[Andi Gutmans]

In PHP/FI 2 functions weren't written like in PHP 3 & 4. Their style was 
something like:
function foo $a $b
(

)
We added the more C-like functions and called it cfunction. Then we decided 
that should be the default so function became old_function and cfunction 
became function.

Andi


At 11:16 PM 4/26/2001 +0200, Sebastian Bergmann wrote:
>   Just curious, what are/were cfunction and old_function?
>
>--
>  sebastian bergmann[EMAIL PROTECTED]
>http://www.sebastian-bergmann.de
>
>  bonn.phpug.de | www.php.net | www.phpOpenTracker.de | www.titanchat.de
>
>--
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
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] Fwd: Re: [PHP-INST] AIX

[Andi Gutmans]

Has this happened to anyone else on AIX?

Maybe the MySQL configure isn't doing something right. It should set a 
#define called HAVE_INT_8_16_32 but I don't seem to find a reference to it 
in any .m4.

Andi

>Date: Thu, 26 Apr 2001 17:22:14 -0500
>To: [EMAIL PROTECTED]
>From: Jacob Steinberger <[EMAIL PROTECTED]>
>Subject: Re: [PHP-INST] AIX
>
>Apache Configured with generic. Though I don't think that matters just yet.
>
>PHP Configured with:
>
>./configure --with-mysql --with-apache=/tmp/AIX/apache_1.3.19 
>--enable-track-vars
>
>I did not specify a path for MySql as I'm not sure if its happy with just 
>the client libs or if it wants the server.
>
>I'm still getting the same error with Gnu Make. The error is from the 
>"Making all in libmysql".
>
>In file included from libmysql.c:9:
>global.h:525: conflicting types for 'int8'
>/usr/include/sys/inttypes.h:622: previous delaration of 'int8'
>global.h:526: warning: redefinition of 'int16'
>/usr/include/sys/inttypes.h:623: warning: 'int16' previously declared here
>global.h:536: warning: redefinition of 'int32'
>/usr/include/sys/inttypes.h:624: warning: 'int32' previously declared here
>libmysql.c: In function 'connect2':
>libmysql.c:179: warning: passing arg 5 of 'getsockopt' from incompatible 
>pointer type
>
>After this, it just errors out and reports leaving directories.
>
>Oy!
>
>Jacob
>
>
>--
>PHP Install 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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Fwd: Re: [PHP-INST] AIX

[Andi Gutmans]

Hey guys,

Any idea why HAVE_INT_8_16_32 wasn't defined correctly for this guy 
configuring PHP on AIX? I don't know the autoconf stuff too well but I 
couldn't find any test for this in the libmysql source that sits in the PHP 
CVS.
Maybe we are missing something in our CVS?

Thanks.
Andi

>Date: Thu, 26 Apr 2001 18:22:37 -0500
>To: Andi Gutmans <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>From: Jacob Steinberger <[EMAIL PROTECTED]>
>Subject: Re: [PHP-INST] AIX
>
>Looks like that fixed everything. Now I'm just dealing with user/pass 
>issues so at least its making it to the SQL DB. Simple enough things that 
>I can handle myself. =)
>
>Many thanks Andi!
>
>At 01:27 AM 4/27/01 +0200, Andi Gutmans wrote:
>>A temporary hack which might work is editing ext/mysql/libmysql/global.h 
>>and change all occurances of:
>>#ifndef HAVE_INT_8_16_32
>>to:
>>#if 0
>>
>>Andi
>>
>>
>>At 05:22 PM 4/26/2001 -0500, Jacob Steinberger wrote:
>>>Apache Configured with generic. Though I don't think that matters just yet.
>>>
>>>PHP Configured with:
>>>
>>>./configure --with-mysql --with-apache=/tmp/AIX/apache_1.3.19 
>>>--enable-track-vars
>>>
>>>I did not specify a path for MySql as I'm not sure if its happy with 
>>>just the client libs or if it wants the server.
>>>
>>>I'm still getting the same error with Gnu Make. The error is from the 
>>>"Making all in libmysql".
>>>
>>>In file included from libmysql.c:9:
>>>global.h:525: conflicting types for 'int8'
>>>/usr/include/sys/inttypes.h:622: previous delaration of 'int8'
>>>global.h:526: warning: redefinition of 'int16'
>>>/usr/include/sys/inttypes.h:623: warning: 'int16' previously declared here
>>>global.h:536: warning: redefinition of 'int32'
>>>/usr/include/sys/inttypes.h:624: warning: 'int32' previously declared here
>>>libmysql.c: In function 'connect2':
>>>libmysql.c:179: warning: passing arg 5 of 'getsockopt' from incompatible 
>>>pointer type
>>>
>>>After this, it just errors out and reports leaving directories.
>>>
>>>Oy!
>>>
>>>Jacob
>>>
>>>
>>>--
>>>PHP Install 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]

Re: [PHP-DEV] PHP 4.0 Bug #10343 Updated: Mail function does not work ...

[Andi Gutmans]

Yeah but doesn't this function use sendmail with is suid root?

Andi

At 08:13 AM 4/27/2001 +, [EMAIL PROTECTED] wrote:
>ID: 10343
>User Update by: [EMAIL PROTECTED]
>Status: Open
>Bug Type: Mail related
>Description: Mail function does not work ...
>
>OK, I've found it !
>Like i say in the previous message, it was a security problem.  By 
>default, only the user root and the user mail were able to use the 
>/var/spool/mail directory !
>
>So, changed the security on this folder and the mail funtion works now ...
>
>
>
>Previous Comments:
>---
>
>[2001-04-16 09:33:52] [EMAIL PROTECTED]
>OK, i know that i'm not the only one to have this little problem whit PHP 
>4.04pl1.
>In fact, when you want to use the mail function, it doesn't work : you do 
>not receive any mail or errors !
>But when i look at the Syslog, it seems that's a security problem :
>
>f3GDFxv24454: SYSERR(apache): Can't create transcript file 
>./xff3GDFxv24454: Permission denied
>f3GDFxv24454: SYSERR(apache): Cannot create ./dff3GDFxv24454: Permission 
>denied
>f3GDFxv24454: from=apache, size=0, class=0, nrcpts=0, relay=apache@localhost
>
>Very strange isnt'it ?  A mail from apache(the user account used to run 
>http daemon) with no recipient and no mail data !
>
>Can someone help me ? This would be the solution for a lot of people 
>having the same problem.
>
>Thanks.
>
>Fabian.
>
>
>---
>
>
>Full Bug description available at: http://bugs.php.net/?id=10343
>
>
>--
>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] PHP 4.0 Bug #9933 Updated: readdir doesn't work see Bug ID # 9058

[Andi Gutmans]

At 12:34 PM 4/27/2001 +0200, Sascha Schumann wrote:
>On Fri, 27 Apr 2001, Andi Gutmans wrote:
>
> > Larry,
> > You are right if this code refers to the POSIX semantics of readdir_r.
> > However, this code is in #if defined(HAVE_OLD_READDIR_R) and I don't know
> > what is meant by old readdir_r (different semantics?).
> > Sascha? Can you shed some light on this?
>
> It is a non-standard readdir_r commonly found on SysV
> platforms and derivatives.

So what does that mean? The code is OK there and it isn't reached on 
systems where readdir_r returns 0 for success? I'm not quite sure what to 
do with this bug report.

Andi


-- 
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] function table / hashes

[Andi Gutmans]

At 01:10 PM 4/27/2001 +0100, Wez Furlong wrote:
>On 2001-04-27 11:27:55, "Andi Gutmans" <[EMAIL PROTECTED]> wrote:
> > At 12:03 AM 4/27/2001 -0400, David Croft wrote:
> >
> > >Thank you Andi and Andrei.
> > >
> > >I have noticed that object method callbacks are consistently faster
>than
> > >global function callbacks, and was wondering why:
>
>Perhaps because the method only needs to be found in the hash for the
>object?

It shouldn't really make a difference because it's a hash table.

Andi


-- 
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] Troubles with DL'ed module

[Andi Gutmans]

Did you compile with debug on or off?
Please try without debug in both PHP and your module and let us know if 
something changes.
Also can you try and load it via php.ini (extension=module.so) and not with 
dl().

Andi

At 01:41 PM 4/27/2001 -0500, Brian Foddy wrote:
>I'm having strange problems with a new DL module I'm trying to write.
>The most common problem is PHP will coredump after my
>module has executed in the module cleanup routines (the Zend routines,
>not my module routines).
>
>For instance it will coredump on cleaning up the
>10th constant defined by my module.  It cores at
>line 643 of zend_hash.c (the pefree line).  Looking
>in the debugger, the address looks valid, but free doesn't
>like it.  NOTE:  The constants are defined with
>CONST_CS | CONST_PERSISTENT, but taking the Persistent
>out has no effect (the persistent flag is still set in the struct).
>
>If I remove all my constants, or make other alterations
>it may core in other but related places inside the cleanup.
>
>I'm doing most of this on Solaris 2.6 (sparc) with the Workshop
>compiler (Forte 6.1), but it seems to work ok on Linux and gcc.
>
>I'm not to the point of calling this a Zend bug and
>opening a bug report, but I'm hoping to get a few more pointers
>of how to proceed.  I haven't tried compiling the module
>yet directly into PHP.  I'm rechecking my compile flags,
>for example I added -KPIC to the compile but that didn't help.
>
>BTW, the base PHP I'm building against is 4.0.4p2.
>
>Any help would be greatly appreciated...
>Brian
>
>--
>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] intval($resource)

[Andi Gutmans]

At 06:03 PM 4/27/2001 -0400, Joe Brown wrote:
>Run into a spot of trouble using Metabase(db wrapper) because of it's use of
>casting a $var=intval($resource) where OCIFreeCursor fails to function after
>it has been casted.
>
>Guessing that it fails because intval is creating a reference to the
>resource, in turn OCI does not release the resource because there additional
>reference exist.
>
>I'd like to start working on fixing this, but don't know which behaviour to
>attack.  Does OCI need to be fixed or intval()?
>
>Suggestions anyone...

Is there a good reason it needs to use intval() on the resource? To be 
quite honest intval() shouldn't really return a valid value for resources 
and just by chance it returns the resource id which is probably not a good 
thing.
We can try and look into fixing this problem though.

Andi


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

Re: [PHP-DEV] Troubles with DL'ed module

[Andi Gutmans]

At 12:20 AM 4/28/2001 -0500, Brian Foddy wrote:
>Both were compiled with debug ON.  I'll try them off.
>I'm away for the weekend but will try it Sunday night or Monday.

There is a known bug that if you load a shared library with dl(), compiled 
with debug and it leaks memory that it will crash. Try loading it via 
php.ini and let us know if it helps.

Andi


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

Re: [PHP-DEV] intval($resource)

[Andi Gutmans]

At 08:28 AM 4/28/2001 -0400, Joe Brown wrote:
>Having said that,
>1. is there a good reason OCI shouldn't free the resource reguardless of the
>reference count?

There are different ways to look at this. Some people might think it should 
and some might think it shouldn't. I'm not even completely sure this is 
consistent across all the db modules of PHP.


>2. Should intval not pump up the refcount when doing something silly like
>converting a resource to an integer?

There was a bug in the Zend engine which is at least partially the reason 
for you seeing the behavior you saw. Zeev fixed it a few minutes ago. I 
suggest you try and use the latest CVS and let us know how it goes for you.

Andi


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

Re: [PHP-DEV] intval($resource)

[Andi Gutmans]

At 08:50 PM 4/28/2001 +0200, Thies C. Arntzen wrote:
>On Sat, Apr 28, 2001 at 06:12:19PM +0200, Andi Gutmans wrote:
> > At 08:28 AM 4/28/2001 -0400, Joe Brown wrote:
> > >Having said that,
> > >1. is there a good reason OCI shouldn't free the resource reguardless 
> of the
> > >reference count?
>
> the problem is that freeing resources that are still in use
> will cause trouble once we try to use them (and expect they
> are still there)

Well it will cause a warning because the resource doesn't exist anymore but 
I don't think it would cause serious problems. In any case, I think there 
are two ways to look at this and none is really more correct than the other.

Andi


-- 
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] dirname() implementation question

[Andi Gutmans]

At 02:42 PM 4/28/2001 -0400, Sean R. Bright wrote:
>What was the thinking behind this bit of code from dirname()
>(ext/standard/string.c:799):
>
>PHPAPI void php_dirname(char *path, int len)
>{
> ...
>
> /* Strip trailing slashes */ <--- This?
> while (end >= path && IS_SLASH(*end)) {
> end--;
> }
>
>Why are we stripping trailing slashes?  My thought is that if we have
>something like this:
>
>/etc/passwd/ == Directory
>/etc/passwd  == File
>
>Or was this discussed before I started reading the list?

It was discussed already before.
The semantics of the UNIX dirname is that it strips trailing slashes 
and  the trailing word.

Andi


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

Re: [PHP-DEV] STOP PRODUCTION

[Andi Gutmans]

This problem seems to have been introduced by a fix we made in the Zend 
Engine (not sure yet).
We're looking into it.

Andi

At 06:39 PM 4/28/2001 -0400, Joe Brown wrote:
>Serious problem...
>
>I checked out php4 today, and compiled it on windows and linux.
>
>The bang (!) in the if statement changes the resource to
>if(!($connection=ociplogon("scott","tiger","orcl"))) {
>var_dump($connection) = resource(1) of type (Unknown)
>w/out the bang(!)
>if(($connection=ociplogon("scott","tiger","orcl"))) {
>var_dump($connection) = resource(1) of type (oci8 connection)
>
>This code fails miserably:
>
>$connection=0;
>$statement=0;
>if(!($connection=ociplogon("scott","tiger","orcl"))) {
>   echo "above result is false, so this will probably never happen\n";
>}
>var_dump($connection);
>$query = "select user from dual";
>$statement=OCIParse($connection,$query);
>OCIExecute($statement);
>OCIFetch($statement);
>echo OCIResult($statement,1)."\n";
>OCIFreeStatement($statement);
>?>
>
>
>
>--
>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] STOP PRODUCTION

[Andi Gutmans]

Please try the latest Zend CVS.
Also, if you're going to use an Email address which doesn't work at least 
set your Reply-To: field to php-dev.

Andi

At 06:39 PM 4/28/2001 -0400, you wrote:
>Serious problem...
>
>I checked out php4 today, and compiled it on windows and linux.
>
>The bang (!) in the if statement changes the resource to
>if(!($connection=ociplogon("scott","tiger","orcl"))) {
>var_dump($connection) = resource(1) of type (Unknown)
>w/out the bang(!)
>if(($connection=ociplogon("scott","tiger","orcl"))) {
>var_dump($connection) = resource(1) of type (oci8 connection)
>
>This code fails miserably:
>
>$connection=0;
>$statement=0;
>if(!($connection=ociplogon("scott","tiger","orcl"))) {
>   echo "above result is false, so this will probably never happen\n";
>}
>var_dump($connection);
>$query = "select user from dual";
>$statement=OCIParse($connection,$query);
>OCIExecute($statement);
>OCIFetch($statement);
>echo OCIResult($statement,1)."\n";
>OCIFreeStatement($statement);
>?>
>
>
>
>--
>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] MySQL problems at bugs.php.net

[Andi Gutmans]

I can't connect to the machine :'(

Andi

At 02:53 AM 4/29/2001 -0400, David Croft wrote:

>Also unable to fork errors on the search page, and it's been VERY slow
>recently.
>
>--
>|> /+\ \| | |>
>
>David Croft
>Infotrek
>On Sun, 29 Apr 2001, Zak Greant wrote:
>
> > Hello All,
> >
> > I just noted a problem at bugs.php.net:
> >
> > Warning:  MySQL Connection Failed: Can't create a new thread (errno
> > 11). If you are not out of available memory, you can consult the manual for
> > a possible OS-dependent bug
> >  in /local/Web/sites/phpweb/bugs.php on line 77
> > Unable to connect to SQL server.
> >
> > Ciao,
> >
> > --zak
> >
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > To contact the list administrators, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP 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: Crypt salts not random.. (fwd)

[Andi Gutmans]

The seed was initialized in MINIT before the children forked. So what 
happened was that the children started returning the same random numbers.

Andi

At 12:52 PM 4/29/2001 +0300, Zeev Suraski wrote:

>How did you arrive to the conclusion that the current crypt() salts are 
>not random?
>
>
>At 11:27 29/4/2001, Jani Taskinen wrote:
>
>>Well, what's the deal with this? Sascha?
>>
>>--Jani
>>
>>
>>-- Forwarded message --
>>Date: Sat, 28 Apr 2001 15:05:08 +0200
>>From: Andi Gutmans <[EMAIL PROTECTED]>
>>To: Jani Taskinen <[EMAIL PROTECTED]>
>>Subject: Re: Crypt salts not random..
>>
>>At 06:17 AM 4/28/2001 +0200, Jani Taskinen wrote:
>>
>> >One thing I had in my mind about these random numbers..
>> >Why don't we use the seedMT() and randomMT() funcs everywhere
>> >instead of the system provided ones? If I have understood
>> >correctly these would give more random numbers and are even
>> >faster than any of the system provided ones? Or have I missed
>> >some important thing here? :)
>>
>>I really don't know this random stuff too well. It looks to me as if we
>>could use the MT stuff but I'm not sure what the considerations are.
>>
>>Probably Sascha Schumann has a better idea. I also suggest php-dev :)
>>Andi
>>
>>
>>--
>>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 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: Crypt salts not random.. (fwd)

[Andi Gutmans]

At 01:55 PM 4/29/2001 +0300, Zeev Suraski wrote:
>At 13:58 29/4/2001, Andi Gutmans wrote:
>>The seed was initialized in MINIT before the children forked. So what 
>>happened was that the children started returning the same random numbers.
>
>It doesn't really matter where it was initialized, but rather, when it was 
>initialized...


Well as it was initialized in MINIT it is initialized *exactly* at the same 
time for all apache children. Therefore, the numbers returned by each child 
are the same.


>Jani - are you getting the same values after 5 reloads?  Or any chance 
>you're getting the same value if you're reloading very quickly, at the 
>same second?


Andi


-- 
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: Crypt salts not random.. (fwd)

[Andi Gutmans]

At 02:05 PM 4/29/2001 +0300, Zeev Suraski wrote:
>At 14:57 29/4/2001, Andi Gutmans wrote:
>>At 01:55 PM 4/29/2001 +0300, Zeev Suraski wrote:
>>>At 13:58 29/4/2001, Andi Gutmans wrote:
>>>>The seed was initialized in MINIT before the children forked. So what 
>>>>happened was that the children started returning the same random numbers.
>>>
>>>It doesn't really matter where it was initialized, but rather, when it 
>>>was initialized...
>>
>>
>>Well as it was initialized in MINIT it is initialized *exactly* at the 
>>same time for all apache children. Therefore, the numbers returned by 
>>each child are the same.
>
>In order to avoid this you actually have to call it at completely 
>different times, something you can't really guarantee.  We should probably 
>not use the timestamp as the seed (at least not alone), but also take the 
>pid into account.

Jani has already moved it to RINIT which is a good beginning. Adding the 
pid is a good idea. Is there a function which gives us the pid for both 
threaded and un-threaded modes? Or do we need to use #ifdef ZTS and use the 
tsrm_thread_id() function in threaded mode and getpid() in non-threaded?

Andi


-- 
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: Crypt salts not random.. (fwd)

[Andi Gutmans]

At 02:35 PM 4/29/2001 +0300, Zeev Suraski wrote:
>At 15:27 29/4/2001, Andi Gutmans wrote:
>>Jani has already moved it to RINIT which is a good beginning.
>
>It may be a good beginning functionality wise, but it might not be a very 
>good beginning performance-wise.  We should probably do it JIT.

Well Jani's patch doesn't do it each time. It just does it the first time 
RINIT is called.

Andi


-- 
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: Crypt salts not random.. (fwd)

[Andi Gutmans]

At 02:50 PM 4/29/2001 +0300, Zeev Suraski wrote:
>So it's probably not a lot more random than it was before...

I think it is because the time of the rinit()'s are different now (unless 
some of them run at exactly the same time).

Andi


>Zeev
>
>At 15:44 29/4/2001, Andi Gutmans wrote:
>>At 02:35 PM 4/29/2001 +0300, Zeev Suraski wrote:
>>>At 15:27 29/4/2001, Andi Gutmans wrote:
>>>>Jani has already moved it to RINIT which is a good beginning.
>>>
>>>It may be a good beginning functionality wise, but it might not be a 
>>>very good beginning performance-wise.  We should probably do it JIT.
>>
>>Well Jani's patch doesn't do it each time. It just does it the first time 
>>RINIT is called.
>>
>>Andi
>
>--
>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] Interbase problem

[Andi Gutmans]

Hi,

Can you please check the following bug report?
http://www.php.net/bugs.php?id=10458&edit=1

Thanks,

Andi


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

Re: [PHP-DEV] Re: Crypt salts not random.. (fwd)

[Andi Gutmans]

At 10:22 AM 4/29/2001 -0400, John Donagher wrote:
>On Sun, 29 Apr 2001, Zeev Suraski wrote:
>
> > In order to avoid this you actually have to call it at completely 
> different
> > times, something you can't really guarantee.  We should probably not use
> > the timestamp as the seed (at least not alone), but also take the pid into
> > account.
> >
> > Zeev
> >
>
>That only really works for forking webservers, does it not? Another 
>alternative
>would be to use microseconds...

Yeah we could use microseconds but are they available on all platforms?
In any case, on non-forking servers we can use thread id.

Andi


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

[PHP-DEV] 4.0.6

[Andi Gutmans]

Guys,

I think that despite the release of 4.0.5 tomorrow we are pretty close to 
having an RC1 for 4.0.6. Lots of things have been fixed/added since 4.0.5 
(check the NEWS file).
Can we make a list of things which still need to make it into 4.0.6 before 
we branch?

Andi


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

Re: [PHP-DEV] Re: Crypt salts not random.. (fwd)

[Andi Gutmans]

At 09:42 PM 4/29/2001 +0200, Jani Taskinen wrote:

>This is the line in question:
>
>php_srand(time(0) * getpid() * (php_combined_lcg() * 1.0));
>
>This is now (in my patch) in RINIT and thus it is a different pid
>it doesn't matter if the RINIT happens the same second..
>Or did I misunderstood something? And I know it works now. :)
>And it didn't work before. As the PID was always the same like Andi said.
>
>I attached the patch in case you missed it before..

It's OK but in multi-threaded mode it should use "(long) tsrm_thread_id()" 
because getpid() will usually be the same. I hope the case is good enough 
and will work in all multi-threaded environments.

Andi


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