Re: [PHP-DEV] Include a file from inside an extension...

[Andi Gutmans]

You are probably best off using zend_eval_string() and eval "include 
"$myfile.inc;".

Andi

At 04:51 PM 1/7/2003 +, Stefano Corsi wrote:
Hello,

does someone understand if this is the right procedure to include a filename
from inside a C extension?

MAKE_STD_ZVAL(filename_z);
ZVAL_STRING(filename_z, "myfile.inc", 1);
op = compile_filename(ZEND_INCLUDE, filename_z);
zend_execute(op TSRMLS_CC);

Thanks,
Stefano


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



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

Re: [PHP-DEV] size of session vars

[Andi Gutmans]

Hi,

Lately, when people start asking php-general questions on php-dev people 
give them the answer and add "but you should have asked on the php-general 
list". Having received a good answer from php-dev gives them incentive to 
mail us again :)
I suggest we keep to the standard polite reply that they should please mail 
php-general without giving them the answers.

Andi

At 04:26 AM 1/8/2003 -0700, Rick Widmer wrote:
At 10:52 AM 1/8/03 +0100, Hannes Smit wrote:

Does anyone know how much space can be stored in a session?



How much free space do you have on the drive that holds the session 
data?  I don't think there is an arbitrary limit on session size.  Just 
the limitations of the resources of your machine.


This thread probably belongs on php-general.  This list is for the 
development _of_ php, not _with_ php.

Rick


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


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

Re: [PHP-DEV] bcmath, calendar, ftp, wddx on Win32

[Andi Gutmans]

At 06:36 PM 1/9/2003 +0100, Sebastian Bergmann wrote:

  For as long as I can remember, the bcmath, calendar, ftp and wddx
  extensions are enabled by default on Win32.

  But why? I mean, they are not enabled by default on *NIX, so why the
  inconsistency?


Because building this stuff on Windows is harder and it's probably easiest 
for Windows users to have stuff in by default.

Andi


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

Re: [PHP-DEV] What headers/libs does Win32 Snaps build use?

[Andi Gutmans]

At 01:31 AM 1/8/2003 +0100, Edin Kadribasic wrote:

Yes, Steph is right, the set of libraries used on the snaps machine is ~70MB
(uncompressed) and I don't think it's practical to update win32build.zip to
include them all. And this 70 MB does not include files needed for building
ext/infromix, ext/interbase and sapi/pi3web.


I actually think the more complete we can make the win32build.zip the better.
Andi


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

RE: [PHP-DEV] bcmath, calendar, ftp, wddx on Win32

[Andi Gutmans]

At 12:25 PM 1/10/2003 +0100, Lukas Smith wrote:

> From: Andi Gutmans [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 10, 2003 12:14 PM
>
> At 06:36 PM 1/9/2003 +0100, Sebastian Bergmann wrote:
> >   For as long as I can remember, the bcmath, calendar, ftp and wddx
> >   extensions are enabled by default on Win32.
> >
> >   But why? I mean, they are not enabled by default on *NIX, so why
the
> >   inconsistency?
>
> Because building this stuff on Windows is harder and it's probably
easiest
> for Windows users to have stuff in by default.
>

So once the PEAR installer is able to handle binaries for windows in a
reliable fashion this could be changed?



The big difference between Windows and UNIX is that you can usually compile 
on UNIX systems. But if PEAR handles binaries this way, if and when that 
happens, then yes.

Andi



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

Re: [PHP-DEV] PROPOSAL: default value handling

[Andi Gutmans]

This has been discussed in the past and won't be done.
PHP behaves like C where the result of the boolean "or" operation is true 
or false.

Andi

At 12:38 AM 1/11/2003 -0500, Nyk Cowham wrote:
As a convert from Perl one of the 'features' I miss from Perl is the 
short-circuit behavior of the or operand (||) and how it can be used to 
set default values if a passed value is false (0 or ""). Thus, in a passed 
parameter you can write:

$result = $value || $default;

In perl if the $value variable is false (0 or empty string) then $value 
will be set to the default value.

In PHP the or operand does not short-circuit in this way. Instead I find 
myself having to write something like:

$result = ($_REQUEST['value']) ? $_REQUEST['value'] : 'my default 
value';

This is not only ugly and difficult to read but has the redundancy of 
naming the $_REQUEST['value'] variable twice.

Another nice feature of using Perl's short-circuit or operand is that 
defaults can be chained so:

$result = $value || $alt_value || $default;

Will return the default only if $value and $alt_value have both evaluated 
as false. In other words the first expression that evaluates as true 
(actually 'not false' would be more accurate) will be returned, all 
preceding and subsequent values will be ignored.

I don't propose the || operant in PHP should be short-circuited like Perl, 
but rather either a new operand or new function be added that would have 
this specific behavior.

As an operand it might look like:

$result = $value ?: $alt_value ?: [ ...] ?: $default; // reusing 
the terniary operator in this context would be a reasonable mnemonic.

Alternatively if implemented as a function it might look like:

$result = choose($value, $alt_value, [ ... ], $default);

I would be happy to volunteer to do the work to provide this feature if 
there is enough support for it's inclusion. Thoughts?

Nyk Cowham


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


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

Re: [PHP-DEV] Non threadsafe Windows build

[Andi Gutmans]

At 07:13 AM 1/11/2003 +0100, Sebastian Bergmann wrote:

  The project file(s) for the non threadsafe Windows build are out of
  sync with the thread safe one(s).

  IIRC, there was already some discussion to ditch the non threadsafe
  version. That way we didn't have to maintain two sets of files, etc.

  What do you think?


The non-threadsafe version is useful for Windows CGI and debugging. On the 
other hand, it's quite a drag to maintain. Unless someone steps up and 
takes responsibility to keep it in sync, or we make a new rule that people 
have to remember to update both projects, then I think nuking it is OK.
What do others think? (I'm interested in hearing from Windows users)
Andi


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

Re: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c

[Andi Gutmans]

At 12:38 AM 1/12/2003 +0100, Sascha Schumann wrote:

On Sun, 12 Jan 2003, Moriyoshi Koizumi wrote:

> On Sun, Jan 12, 2003 at 12:12:39AM +0100, Sascha Schumann wrote:
> > As many past security advisories have shown, signedness
> > issues are the frequent cause for severe vulnerabilities in
> > software (recent examples include MySQL, OpenBSD kernel).
>
> Actually codes like below produce vulnerble runtimes because
> the length of string is expected to be a positive integer value...

Yes, unfortunately.  Basically the same problem as in the
OpenBSD kernel and its select syscall:

http://www.phrack.org/phrack/60/p60-0x06.txt

Quote:

Whilst there is a check [1] on the 'nd' argument (nd represents the highest
numbered descriptor plus one, in any of the fd_sets), which is checked
against the p->p_fd->fd_nfiles (the number of open descriptors that the
process is holding), this check is inadequate -- 'nd' is declared as signed
[6], so it can be negative, and therefore will pass the greater-than check
[1].

Then 'nd' is put through a macro [2], in order to calculate an unsigned
integer, 'ni', which will eventually be used as the the length argument for
the copyin operation.


I might be misunderstanding the problem and I didn't have time to read the 
phrack article, but doesn't this mean that leaving it unsigned is better? 
It wouldn't pass the length check and thus, memcpy() wouldn't convert a 
negative number to something huge.

Andi


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

Re: [PHP-DEV] Reducing the number of system calls for includes

[Andi Gutmans]

I can't really think of any way of getting around this. include_once() and 
require_once() are basic language constructs and they require this.
There is no way I can think of to cache these results because they often 
depend on include_path and cwd which might change. Yes, we could try and 
think of all the things which could effect it and use those as part of a 
hash key but frankly, smart OS's like Linux don't take too long and the 
file system cache usually works pretty well.

Andi


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

Re: [PHP-DEV] Reducing the number of system calls for includes

[Andi Gutmans]

At 04:06 PM 1/24/2003 -0800, Rasmus Lerdorf wrote:

> 5. Looking at Linux's syscall implementation and implementing
> the good ideas in FreeBSD.

Well yes, but fixing the os is pretty drastic.  For now I will be patching
things here to short-circuit all that stuff, but I think it is also
something we should look at in general for PHP.

As for numbers, I basically doubled the req/sec rate of a box by
eliminating a bunch of system calls caused by include_path and
open_basedir stat'ing, so in my particular situation here eliminating as
many syscalls as I can is having a direct effect.


What OS are you running on? Are you running over NFS?

Andi


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

Re: [PHP-DEV] Reducing the number of system calls for includes

[Andi Gutmans]

At 04:32 PM 1/24/2003 -0800, Rasmus Lerdorf wrote:

> I can't really think of any way of getting around this. include_once() and
> require_once() are basic language constructs and they require this.

Well, they require us to be able to uniquely identify a file, they do not
necessarily require us to know the canonical filename.  This could be done
in a single stat where we grab the device number and inode.


Yeah but on broken systems single stat's also stat each directory (AFAIK). 
I don't think it's any faster or at least not noticably.
Andi


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

Re: [PHP-DEV] Reducing the number of system calls for includes

[Andi Gutmans]

At 02:42 AM 1/25/2003 +0200, Andi Gutmans wrote:

At 04:32 PM 1/24/2003 -0800, Rasmus Lerdorf wrote:

> I can't really think of any way of getting around this. include_once() and
> require_once() are basic language constructs and they require this.

Well, they require us to be able to uniquely identify a file, they do not
necessarily require us to know the canonical filename.  This could be done
in a single stat where we grab the device number and inode.


Yeah but on broken systems single stat's also stat each directory (AFAIK). 
I don't think it's any faster or at least not noticably.

Just want to correct myself. I don't think it's broken systems but I do 
think stat() is more or less the same as realpath(). It will still 
internally stat() each directory.

Andi


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

Re: [PHP-DEV] Reducing the number of system calls for includes

[Andi Gutmans]

At 04:51 PM 1/24/2003 -0800, Rasmus Lerdorf wrote:

Which broken systems?  Certainly not on FreeBSD or Linux.  A little test:

  stat("/home/rasmus/foo/u2.inc",&sb);

That ends up doing just a single stat on FreeBSD:

stat("/home/rasmus/foo/u2.inc",0x9fbffa0c)   = 0 (0x0)

and on Linux:

stat64("/home/rasmus/foo/u2.inc", {st_mode=S_IFREG|0644, st_size=12, ...}) = 0


Yes you are right. But I still think the advantages of having a canonical 
file path is good. It improves error messages, it allows for open_basedir 
and include_once() to work 100%. I don't think it's worth killing good 
stable functionality for this.

What needs to be taken from your timings is not the relative time of stat() 
vs. realpath() but the absolute times. You can see that on Linux the speed 
of realpath() is 12 microsecond. I don't believe you can feel this in a 
script even if you have tens of realpath()'s per script (at least vs. 
stat()). Now on FreeBSD it takes about half a millisecond. That is much 
more but I'm not sure it's still worth breaking functionality for this.

That said, we could possibly have a fast mode and use fstat() to get some 
device information on the open file. I am worried about functionality 
though. I'm not sure it's worth breaking.

Andi


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

Re: [PHP-DEV] If... Else.. I'm not getting it!

[Andi Gutmans]

This list is only for people who develop PHP and not _with_ PHP.
Please contact a PHP users mailing list such as [EMAIL PROTECTED]

Good luck,

Andi

At 10:24 AM 1/25/2003 +0100, Frank Keessen wrote:

Hi all,

Please can you help me with the following:

If got a little sample code:

This one is working (!):


$vname=$_POST['vname'];
echo "hello $vname";
?>


Input yourname





?>

But when i'm using IF Else.. Nothing is happening. I'm only seeing the 
form but when i submit that form: The $vname doen't display..

Here is the code that doesn't work:


$vname=$_POST['vname'];
if($submit) {
echo "hello $vname";
} else {
?>


Input yourname




}
?>

What am I doing wrong???

Thanks,

Frank


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

Re: [PHP-DEV] Reducing the number of system calls for includes

[Andi Gutmans]

At 02:30 AM 1/25/2003 -0800, Rasmus Lerdorf wrote:

> That said, we could possibly have a fast mode and use fstat() to get some
> device information on the open file. I am worried about functionality
> though. I'm not sure it's worth breaking.

Yes, fstat() is fast.  And perhaps it isn't worth breaking functionality
across the board, but in my particular case I don't really have a choice.
It is simply too slow to handle the loads that it needs to handle and
either I need to get twice as many machines or I need to lose some
functionality.

Another idea would be to try to streamline the normal case for an absolute
pathname.  How about doing a readlink() on it.  If that tells us that it
is a link, then we know there is something funky and we can do a realpath,
otherwise we just assume it is canonical assuming there are no . .. or //
in the filename in which case we fall back to a realpath() as well.


Hmm I'm not sure this would give you what you're looking for. I think it 
only works if the last element of the path is a symbolic link but I might 
be wrong. I'm not quite sure of the semantics of readlink().

Or, the really straightforward dumbass solution, have some hint we can
pass along that tells the parser to treat what follows as a canonical
filename.

  include "\001/home/rasmus/foo/u2.inc";

A bit too hacky I guess.  Perhaps something like:

  include_canonical "/home/rasmus/foo/u2.inc";

And we would simply assume that this is a canonical filename and skip all
the checks.  This last one is probably what I will need to do, but I will
do some tests on the readlink() optimization and see if that buys me
anything.


I think both of these solutions are too hacky. If we end up deciding that 
it makes sense to have a mode which uses fstat() then we should probably 
just document what we believe could break and with a "use this with care!" 
warning.
I'm going to try and think if there are other options which won't break 
functionality.
Andi


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

Re: [PHP-DEV] Reducing the number of system calls for includes

[Andi Gutmans]

Hi,

I think the best solution to this problem, without breaking functionality, 
is to use a cache for realpath() in virtual_file_ex().
This should solve the performance problems and not effect BC at all. As 
TSRM always passes a full path to the realpath() call there, it should 
always work.

Andi

P.S.-Theoretically the only time it could cause problems is if someone, 
while the server is running, changes a symlink in one of the cached paths. 
This is highly unlikely.


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

Re: [PHP-DEV] Again scope

[Andi Gutmans]

At 10:20 PM 2/2/2003 +0100, Maxim Maletsky wrote:


On Sun, 2 Feb 2003 22:06:24 +0100 (CET) Derick Rethans <[EMAIL PROTECTED]> wrote:

> On Sun, 2 Feb 2003, Maxim Maletsky wrote:
>
> > stranno, dovrebbe comunque funzionare datto che ZEND_CHANGES.txt ha quasi
> > un anno mentre il tuo CVS checkout e, credo, sia un sacco piu fresco.
> > Sicuro che non funzioni?
>
> No problem if you answer in italian, but there is no need to CC the list
> then :-)

Sorry, guys - haven't noticed that Michele added php-dev to the
conversation :)  (Should have guessed why his answer was in english)

Anyway, what he talked about was why that code didn't work for him.
Sounded strange to me since it was noted in ZEND_CHANGES.txt.


The file isn't up-to-date. I'll make sure it's correct once namespaces are 
finalized.

Andi


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

Re: [PHP-DEV] RE: zend_API.c

[Andi Gutmans]

Hey,

I think the discussion you guys are having is much broader than just 
mysqli. We should probably come up with a general approach which we will 
use consistently for PHP 5.
I suggest we move this discussion to the PHP 5 dev list and try and come up 
with a good solution. Obviously we will keep the functional support for all 
extensions like PHP 4. The only question is, if and how we support an OO 
paradigm.

Andi


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

Re: [PHP-DEV] PHP 5 mailing list

[Andi Gutmans]

At 03:22 PM 2/3/2003 -0500, Dan Kalowsky wrote:

To all concerned,

I would like to request that yet again the PHP5 mailing list be made
public and no longer kept private.  Given that comments in the past few
hours have centered around the existence of the mailing list, it seems
rather absurd to continue the secrecy notion.

To those who will say it is open for joining, I submit to you the
following considerations.  First there is no mention of said mailing list
existing on the mailing-list tab of the PHP main web site.  Second there
is still no publicly viewable record of what has transpired on the
mailing list (which means the 'read the archives' comment is futile).

I for one find it really annoying to find changes to PHP being done
without discussion.  Only later to find through an IRC channel what was
done and why.


As far as I know the mailing list is open for anyone to subscribe (it is 
moderated). I think a new archive was created which starts about a week ago 
but I'm not sure where it can be accessed.
I am very happy that the mailing-list tab on the PHP main web site doesn't 
include it yet. I'd prefer only people who are active in the developer's 
community (i.e. php-dev, php-qa) to be part it. The last thing we need is 
to have the whole PHP users community on it. We won't get anything done and 
that was the whole reason to keep things small.

Andi
P.S.-I don't think your negative tone was called for.


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

[PHP-DEV] Re: Bug # 13551, bcmath scale:: when to apply

[Andi Gutmans]

Hi,

Indeed I wasn't aware of this bug report. It seems as if your patch is fine 
although I could only look at it briefly.
It does look strange that you need to initialize the resulting scale 
manually. I thought the BC functions are supposed to take care of returning 
the results as the right scale.
In any case, it probably makes sense for you to go ahead and commit it.
BTW, is php_str2num() only supposed to work on whole or decimal values? 
What about exponents? I think you're probably right but I just want to make 
sure you thought about it.
Thanks,

Andi


At 01:51 PM 2/3/2003 -0800, Sara Golemon wrote:
Andi,

  Nicos assigned this bug to you a month ago, but since I've seen no
activity (and it's entirely possible you didn't know he'd assigned it) I
went ahead and took a crack at it.  Would you care to give me the go
ahead to commit/close for you?  ...or tell me to mind my own bugs? :)

Patches against PHP_4_3 and HEAD can be found at:

http://frankenbox.alphaweb.net/test/php_4_3.bcmath.diff.txt

and

http://frankenbox.alphaweb.net/test/HEAD.bcmath.diff.txt

The idea being to automagically determine the scale of the input numbers
so that they are not truncated prior to the op.  Then, once the op has
been performed, reduce the scale to whatever was requested.

The "result->n_scale = scale;" line might look a little dangerous, but
since it only comes after lines which create 'result' with a scale of *at
minimum* 'scale' it means that 'result->n_scale' will always be >= 'scale'
and hence assigning it to 'scale' will always result in a reduction (or no
change at all) and bc_num2str won't go looking in undefined sections of
the bc_num val.

-Pollita

P.S. - This one's for you sniper ;)



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

[PHP-DEV] Re: Bug # 13551, bcmath scale:: when to apply

[Andi Gutmans]

At 11:31 AM 2/4/2003 -0800, Sara Golemon wrote:


> BTW, is php_str2num() only supposed to work on whole or decimal values?
> What about exponents?
>
bc_str2num() only allows whole or decimal values so that's all I wrote
php_str2num to allow for.
By 'exponents' do you mean scientific notation?  I don't see any support
for that in the bc conversion functions.  I don't suppose it would take
much to add that capability, but that'd be a feature change and should
probably be done separately (and only in HEAD).


Nah, if it doesn't support scientific notation then I'd leave it.
IMO, just go ahead and commit.
Andi


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

Re: [PHP-DEV] [PATCH] new idate() - sunrise() - sunset() functions

[Andi Gutmans]

I haven't been following this whole discussion.
However, the function names should follow the coding standards and be named 
something like date_sunrise(), date_sunset() (or whatever other prefix 
makes sense).

Andi

At 05:02 PM 2/6/2003 +0200, Moshe Doron wrote:

"Zeev Suraski" <[EMAIL PROTECTED]> wrote in message 
5.1.0.14.2.20030206161428.050f11c0@localhost">news:5.1.0.14.2.20030206161428.050f11c0@localhost...
> At 13:36 06/02/2003, moshe doron wrote:
> > b. sunrise()
> > c. sunset()
>
> Hrm, what are these functions?


* {{{ proto mixed sunrise(mixed time[, double latitude][, double 
longitude][, double zenith,][ double gtm_offset][, int format])
   Returns time of sunrise for a given day & location */

/* {{{ proto mixed sunset(mixed time[, double latitude][, double 
longitude][, double zenith,][ double gtm_offset][, int format])
   Returns time of sunset for a given day & location */

i wrote those functions as infrastructures for the calendar extension for 
returning optionaly the 'real' date depending on the calendar native e.g, 
the jewish dayes are "come by the night" mean the day is changed on sunset.

the information is is also used for other religion tasks (e.g, jewish and 
arabic  prayer times), for astronomy studies and for travelers design.


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

Re: [PHP-DEV] [PATCH] new idate() - sunrise() - sunset() functions

[Andi Gutmans]

At 12:47 PM 2/7/2003 +0200, moshe doron wrote:

"Andi Gutmans" <[EMAIL PROTECTED]> wrote in message 
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> I haven't been following this whole discussion.
> However, the function names should follow the coding standards and be 
named
> something like date_sunrise(), date_sunset() (or whatever other prefix
> makes sense).
>

here is part of my replay to Leon Atkinson:
> Also, shouldn't sunrise() and sunset() be cal_sunrise() and cal_sunset()?
>
well, since sunset() & sunrise() have aspects more then cal_* related, i 
thought the right place is standard.

new astronomy extension, or linking against exisint lib, 'll be overhead 
since i want use it on the calendar extension, that is build by default on VC.

Even functions in standard have a prefix. Only ancient ones don't and we 
didn't fix them for BC reasons.

Andi


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

Re: [PHP-DEV] [PATCH] new idate() - sunrise() - sunset() functions

[Andi Gutmans]

At 02:37 PM 2/7/2003 +0200, moshe doron wrote:

well, what about  sun_set(), sun_rise()?


I hope you're kidding.

Andi


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

Re: [PHP-DEV] [patch] solaris getcwd() brokeness

[Andi Gutmans]

Hey,

The fchdir() part of the patch looks fine but I didn't quite understand the 
rest. PHP only uses realpath() if it doesn't fail, so what is the exact 
problem? What does that other code do?

Andi

At 03:29 PM 2/12/2003 -0500, James E. Flemer wrote:
Well all the fancy new streams code in 4.3.0 seems to
tickle a Solaris issue with getcwd().  It seems that under
certain cases solaris' getcwd() fails when other os' work.
Consequently 4.3.0 causes a huge ammount of breakage for
some sites running solaris.  Below is a patch that seems to
work around the problem.  This may not be the best
approach, but it was an attempt at a quick-fix so that
4.3.0 would be usable for now.  This problem has bug
number: #21310 [1].  Comments welcome.  I'd like to commit
this (or similar) before any more releases are made.

-James <[EMAIL PROTECTED]>

[1] http://bugs.php.net/21310

]] Patch sponsored by: The University of Vermont [[
Index: TSRM/tsrm_virtual_cwd.c
===
RCS file: /repository/TSRM/tsrm_virtual_cwd.c,v
retrieving revision 1.41
diff -u -b -u -r1.41 tsrm_virtual_cwd.c
--- TSRM/tsrm_virtual_cwd.c 6 Nov 2002 18:07:22 -   1.41
+++ TSRM/tsrm_virtual_cwd.c 12 Feb 2003 04:39:11 -
@@ -303,7 +303,7 @@
return (0);

 #if !defined(TSRM_WIN32) && !defined(NETWARE)
-   if (IS_ABSOLUTE_PATH(path, path_length)) {
+   if (IS_ABSOLUTE_PATH(path, path_length) || (state->cwd_length < 1))
{
if (use_realpath && realpath(path, resolved_path)) {
path = resolved_path;
path_length = strlen(path);
@@ -363,6 +363,7 @@
}


+  if (state->cwd_length > 0 || IS_ABSOLUTE_PATH(path, path_length)) {
ptr = tsrm_strtok_r(path_copy, TOKENIZER_STRING, &tok);
while (ptr) {
ptr_length = strlen(ptr);
@@ -416,6 +417,11 @@
state->cwd[state->cwd_length+1] = '\0';
state->cwd_length++;
}
+  } else {
+   state->cwd = (char *) realloc(state->cwd, path_length+1);
+   memcpy(state->cwd, path, path_length+1);
+   state->cwd_length = path_length;
+  }

if (verify_path && verify_path(state)) {
CWD_STATE_FREE(state);
Index: main/main.c
===
RCS file: /repository/php4/main/main.c,v
retrieving revision 1.512.2.5
diff -u -b -u -r1.512.2.5 main.c
--- main/main.c 16 Dec 2002 15:44:06 -  1.512.2.5
+++ main/main.c 12 Feb 2003 04:39:12 -
@@ -1507,7 +1507,11 @@
 {
zend_file_handle *prepend_file_p, *append_file_p;
zend_file_handle prepend_file, append_file;
+#ifdef VIRTUAL_DIR
char *old_cwd;
+#else
+   int old_cwd_fd;
+#endif
char *old_primary_file_path = NULL;
int retval = 0;

@@ -1515,9 +1519,11 @@
if (php_handle_special_queries(TSRMLS_C)) {
return 0;
}
+#ifdef VIRTUAL_DIR
 #define OLD_CWD_SIZE 4096
old_cwd = do_alloca(OLD_CWD_SIZE);
old_cwd[0] = '\0';
+#endif

zend_try {
 #ifdef PHP_WIN32
@@ -1528,7 +1534,11 @@

if (primary_file->type == ZEND_HANDLE_FILENAME
&& primary_file->filename) {
+#ifdef VIRTUAL_DIR
VCWD_GETCWD(old_cwd, OLD_CWD_SIZE-1);
+#else
+   old_cwd_fd = open(".", 0);
+#endif
VCWD_CHDIR_FILE(primary_file->filename);
}

@@ -1578,10 +1588,14 @@

} zend_end_try();

+#ifdef VIRTUAL_DIR
if (old_cwd[0] != '\0') {
VCWD_CHDIR(old_cwd);
}
free_alloca(old_cwd);
+#else
+   fchdir(old_cwd_fd);
+#endif
return retval;
 }
 /* }}} */
Index: main/safe_mode.c
===
RCS file: /repository/php4/main/safe_mode.c,v
retrieving revision 1.51
diff -u -b -u -r1.51 safe_mode.c
--- main/safe_mode.c6 Nov 2002 18:07:23 -   1.51
+++ main/safe_mode.c12 Feb 2003 04:39:12 -
@@ -121,6 +121,8 @@
VCWD_REALPATH(filename, path);
*s = DEFAULT_SLASH;
} else {
+   path[0] = '.';
+   path[1] = '\0';
VCWD_GETCWD(path, sizeof(path));
}
} /* end CHECKUID_ALLOW_ONLY_DIR */


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



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

Re: [PHP-DEV] [PATCH] (resend) fix for bug #21600 and #22231

[Andi Gutmans]

We'll review it. I think we'll use it almost as-is except that we won't do 
the old check variable_ptr_ptr != value_ptr_ptr
If you don't see anything on this front in the next couple of days please 
remind me.
Andi

At 03:58 AM 2/16/2003 +0900, Moriyoshi Koizumi wrote:
Hi,

Could anyone who has ZE karma review this patch again?

Thanks,

Moriyoshi

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



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

Re: [PHP-DEV] [patch] solaris getcwd() brokeness

[Andi Gutmans]

At 03:41 PM 2/13/2003 -0500, James E. Flemer wrote:

RCS file: /repository/TSRM/tsrm_virtual_cwd.c,v
retrieving revision 1.41
diff -u -b -r1.41 tsrm_virtual_cwd.c
--- TSRM/tsrm_virtual_cwd.c 6 Nov 2002 18:07:22 -   1.41
+++ TSRM/tsrm_virtual_cwd.c 13 Feb 2003 20:40:07 -
@@ -303,7 +303,7 @@
return (0);

 #if !defined(TSRM_WIN32) && !defined(NETWARE)
-   if (IS_ABSOLUTE_PATH(path, path_length)) {
+   if (IS_ABSOLUTE_PATH(path, path_length) || (state->cwd_length < 1)) {
if (use_realpath && realpath(path, resolved_path)) {
path = resolved_path;
path_length = strlen(path);


Will realpath() work in cases where getcwd() didn't work? (btw it's nicer 
to check state->cwd_length == 0 than < 1 IMO).

@@ -363,6 +363,7 @@
}


+  if (state->cwd_length > 0 || IS_ABSOLUTE_PATH(path, path_length)) {
ptr = tsrm_strtok_r(path_copy, TOKENIZER_STRING, &tok);
while (ptr) {
ptr_length = strlen(ptr);
@@ -416,6 +417,11 @@
state->cwd[state->cwd_length+1] = '\0';
state->cwd_length++;
}
+  } else {
+   state->cwd = (char *) realloc(state->cwd, path_length+1);
+   memcpy(state->cwd, path, path_length+1);
+   state->cwd_length = path_length;
+  }


I'm trying to think if there's some other way of doing this. What is the 
main problem in this loop? Does it add  / or c:\ in the beginning of the 
string?

Andi


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

Re: [PHP-DEV] Announcement: Next generation ext_skel

[Andi Gutmans]

It'd be nice to see an example of the XML. I liked the simplicity of 
today's prototype file, I'm not sure XML isn't an overkill.

Andi

At 11:24 AM 2/19/2003 +0100, Hartmut Holzgraefe wrote:

i've just added the first working results of a replacement for the good
old ext_skel script in php/scripts/ext_skel_ng
ext_skel_ng is meant to replace the current ext_skel completely, and IMHO
it is already at least as capable as the old one.
ext_skel_ng is a 'pure' php solution, it only depends on php itself and
the xml extension which is enabled by default
instead of a simple proto file and some command line options it is now
completely driven by an XML file similar to (and inspired by) the PEAR
package.xml format
code generation is already a little more clever than the previous
template apporach, and preliminary support for M$ developer studio
.dsp project files has just been added :)
see the attached README file below for further info ...



- php/scripts/ext_skel_ng/README 

sorry, no real documentation yet ...
just a short look at what is going on
ext_skel_ng.php gets an extension description
from an "extension.xml" file and generates working
code and documentation stubs from that
call "php ext_skel_ng.php" to see it at work,
it will create a dummy extension including
- module globals and ini paramter setup
- function registration and stubbs
- documentation framework
- config.m4 (only minimal for now)
- ...
almost every aspect of an extension may now be
configured using one xml description file instead
of the old mixture of command line parameters
and a proto file
it is even possible to embed function code into
the xml description right away, so it should be
possible to create complete working extensions
from just the xml description without further
editing in a not to distant future
for now almost all the 'helpfull comments' have
been removed from the generated code. some of
them (like 'uncomment this if you have ini params)
just don't make sense anymore, others will come
back (configurable) at a later state
... have fun!

--
Six Offene Systeme GmbH http://www.six.de/
i.A. Hartmut Holzgraefe Email: hartmut@xx   Tel.: +49-711-99091-77
Sie finden uns auf der CeBIT in Halle 6/H44   http://www.six.de/cebit2003/

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


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

Re: [PHP-DEV] Name of variable

[Andi Gutmans]

You can't get the name of the variable. For what purpose do you need it?

Andi

At 03:45 PM 2/22/2003 +0100, Ivan Rodriguez wrote:


Hello, i need to get the name of the variables who passed in one
function, for example:
switch ((*struc)->type) {
case IS_BOOL:
fprintf(_dyn_log_file_fp, "%sbool:%s\n", COMMON,
((*struc)->value.lval?"true":"false"));
break;
With this i get the typo of variable, and what can i do to get the name
of variable?¿?
Thx.

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


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

Re: [PHP-DEV] Name of variable

[Andi Gutmans]

I think xdebug might do it (http://xdebug.derickrethans.nl/) although I've 
never used it.
Andi

At 03:56 PM 2/22/2003 +0100, Ivan Rodriguez wrote:
I need to get the because i doing a simple debugger, and i get the type
of variable and his information , and i would like to get his name, any
possible way does not exist?¿
thx

El sáb, 22-02-2003 a las 15:42, Andi Gutmans escribió:
> You can't get the name of the variable. For what purpose do you need it?
>
> Andi
>
> At 03:45 PM 2/22/2003 +0100, Ivan Rodriguez wrote:
>
>
> >Hello, i need to get the name of the variables who passed in one
> >function, for example:
> >
> >
> >switch ((*struc)->type) {
> > case IS_BOOL:
> > fprintf(_dyn_log_file_fp, "%sbool:%s\n", COMMON,
> >((*struc)->value.lval?"true":"false"));
> > break;
> >
> >
> >With this i get the typo of variable, and what can i do to get the name
> >of variable?¿?
> >
> >Thx.
> >
> >
> >--
> >PHP Development Mailing List <http://www.php.net/>
> >To unsubscribe, visit: http://www.php.net/unsub.php
>
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
>


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


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

Re: [PHP-DEV] Flex never-interactive mode

[Andi Gutmans]

At 12:48 PM 2/26/2003 -0800, Rasmus Lerdorf wrote:
I think we can add "%option never-interactive" to the ini-scanner lexer to
speed it up a tiny little bit.  Speeding up the ini scanner might be
important for the folks running the cgi version.  More importantly, to me
anyway, when we know we are not interactive, should we not
programmatically set is_interactive to false for the language scanner as
well?  I did this here and the ioctl syscalls that come from the isatty()
calls in the lexer dropped away speeding things up nicely.
Do you have any figures? (req/s wise)
I think we can set it to false when we know we're not interactive. It 
shouldn't be a problem.

Andi

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

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

[Andi Gutmans]

Hi,

The reason the zend_parse_parameters() API only exposes long is because the 
Zend zval (container which holds the engine values) only supports longs and 
not ints. So anything which touches scripting engine values should be using 
long. However, extensions which have INI parameters may want to use ints 
for their internal logic. The INI directive retrieval really doesn't have 
anything to do with zval's.
So I think the fix of adding OnUpdateLong() is the correct fix.
We could add some support in ZEND_DEBUG mode to catch some common errors. 
For example, we could make the zend_parse_parameters() function a macro and 
make sure that people are passing long's and not ints. I'm not really sure 
it's worth it though.

Andi

At 06:19 PM 2/28/2003 +0800, James Devenish wrote:
Hi,

Preface: This e-mail uses the distribution list (To and CC addresses)
that the original poster used. I have moved everyone other than php-dev
to Bcc so that this doesn't get perpetuated (I have no idea of the
significance of the other addresses that were e-mailed, nor do I know
Dave Hill's standing in the PHP community).
In message <[EMAIL PROTECTED]>
on Thu, Feb 27, 2003 at 02:52:28PM -0500, Dave Hill wrote:
> Proposed Patch to address 64 bit issues in PHP v4.3.1
> Diff -u against php4-STABLE-200302241430
> Also needed in 4.5.x and 5.x
> Addresses bugs 20994, 21002, 21822, 20268
There was some discussion on php-dev in November 2002 after I posted
patches for bug #20268 (the earliest-numbered one in Dave's list).
> I chose to address this problem by creating OnUpdateLong (in addition to
> to existing OnUpdateInt) and sweep though the code changing the call
> where needed to match the stucture item. An equally valid fix would be
> to change all of those longs to ints.
(a) I also chose to create OnUpdateLong (and this has been working well
for me since 4.3.0pre2 using the patches I posted). Since I posted those
patches, PHP has progressed and more of these problems have been
introduced (bad) but at the same time some of the test cases have been
revised to be more portable (good).
(b) I found that sometimes ints needed to stay as ints and longs needed
to stay as longs, which is why I chose to separate OnUpdateLong from
OnUpdateInt.
(c) In discussions on php-dev in November, the subject of the thread was
"64-bit PHP 4.3 (extensive long vs int problems)"

(d) Jason Greene responded as a person who was working on this problem.
Disfavour of the OnUpdateLong solution was expressed (on- and maybe
off-list, too).
> After performing that sweep, I found there was a small number of other
> errors of the int/long type that my compiler found that I corrected and
> are included here. There might be more mix and match problems, I only
> addressed the ones in the modules I have enabled.
Deja vu!

Now the reason I am responding and the reason I have BCCed the people in
Dave's list was that I wanted to mention something about Zend. Really,
this bug has its roots in Zend though it is manifested in PHP modules.
Firstly, OnUpdateInt assigns to long storage but uses zend_atoi --
clearly there is confusion already. But the more disturbing thing that I
found in November was the Zend documentation for zend_parse_parameters
(a site of extensive long/int problems). That is why I have written this
e-mail.
I know nothing about the Zend engine but I will refer to this document:
 It is entitled
"Accepting Arguments / Retrieving Arguments" and describes the
zend_parse_parameters function. It lists a type specifier:
"l - long"

But it does not list an int type. In the actual code, it is entirely
long-based, not int-based, so there is clearly a mismatch. But moreover,
there is no acknowledgement of the significance of int versus long. So
it is not surprising that so many developers have made mistakes arising
from this.
Therefore, I thought that a proper solution to this problem would have
to involve some consideration of the Zend API (or at least copious
acknowledgments and warnings in its documentation). There is potentially
a huge developer education problem, too. That is why I chose to add
OnUpdateLong. And given the choice, I would have 'i - int' added to the
type specifiers of zend_parse_parameters.
Firstly, having the OnUpdateLong function allows quick rectification of
these problems without having to try to stuff ints into longs or longs
into ints -- we can instead just choose the one that fits the task.
Moreover: by having two functions and two type specifiers (one for ints
and one for longs), the situation would almost be self-documenting:
developers that would usually neglect to consider the difference between
int and long would at least see that there is a 'int' variant and a
'long' variant and therefore be prompted -- without extensive
re-education -- to consider using the correct 'hole' for the 'peg'. If
Zend is to settle on everything being 

Re: [PHP-DEV] CVS Account Request: jay

[Andi Gutmans]

Have you submitted a CVS account request?

At 09:41 PM 2/27/2003 +, J Smith wrote:
A few weeks ago, I kind of volunteered to maintain testing scripts for ZE2 
on the ZE2 mailing list. (See the thread beginning at 
http://www.zend.com/lists/engine2/200302/msg3.html )

Just to make good on my volunteering, I guess I'll be needing a CVS 
account. I suppose I'd need access to php(4|5)/tests. I have a bunch of 
tests ready to go, and will be adding more as features get added, tweaked, 
etc. within ZE2.

As for experience, I've submitted various patches to the project over the 
past year or so and written a few extensions that will eventually make it 
to PECL. I've also offered the use of a Solaris server to the group for 
debugging Solaris SPARC issues and can do some debugging on it myself if 
there's a need for it.

J, aka darkpanda

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


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

Re: [PHP-DEV] Weak references in PHP

[Andi Gutmans]

Hi,

I don't quite understand. If you are thinking of implementing something 
similar to JDO then your persistent object manager will only hold the 
objects which are retrieve by the script. At the end of the request it'll 
persist the changes and will free the objects. Why would you want them to 
be destroyed during the request?

Andi

At 02:39 PM 2/28/2003 +0300, Konstantin Knizhnik wrote:
To be able to implmenet interface of object-oriented database to PHP I need
to
have object cache which will map persistent object identifier (OPID) to
loaded instance of the object. This cache should be "weak", i.e. it should
not prevent garbage collection from deallocating unused instances of
peristent object (otherwise all database will be soon loaded in memory)..
As far as I understand, PHP uses GC bases on refernce couters. Also I do not
find something like weak reference in language manual. There are two other
ways how to solve the problem
without weak references:
1. Be able to check valye of reference counter (so I can check the it is
equal to 1 and if so remove this object from object cache)
2. Be able to detect the moment when object is removed by GC (in this case I
can make object cache invisible for GC and when object is deleted, it will
be also unlinked frmo object cache).
Can anybody tell me if such features are available in PHP (I failed to find
them myself).
Or may be there is some other way to solve the problem?
Thanks in advance
Konstantin


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


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

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

[Andi Gutmans]

At 04:28 PM 2/28/2003 +0100, Sascha Schumann wrote:
> So I think the fix of adding OnUpdateLong() is the correct fix.

I was under the impression that OnUpdateInt was actually
expecting a long.  I remember changing some int's to long's
to address 64 bit issues.  Do I remember this incorrectly?
No, you are correct but misunderstood me. We should introduce 
OnUpdateLong() for ppl using longs and use OnUpdateInt() for ppl who want 
to use ints.

Andi

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

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

[Andi Gutmans]

At 04:47 PM 2/28/2003 +0100, Sascha Schumann wrote:
> No, you are correct but misunderstood me. We should introduce
> OnUpdateLong() for ppl using longs and use OnUpdateInt() for ppl who want
> to use ints.
Well, and how are you planning to mitigate the BC issues?
Remember that not all extension code is under our direct
control.
I don't think there's much choice. Do you have a better idea? If so, please 
explain it.

Andi

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

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

[Andi Gutmans]

At 04:50 PM 2/28/2003 +0100, Sascha Schumann wrote:
I think that simply adding OnUpdateLong and deprecating
OnUpdateInt is fine while retaining its current semantics.  I
just don't see any value in changing the meaning of
OnUpdateInt; at least that's how I interpreted Andi's
message.
That's also an option but I think OnUpdateInt() is confusing and how do we 
stop ppl from using it in new extensions which who's commit messages aren't 
followed via php-cvs?

Andi

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

Re: [PHP-DEV] #php.bugs invite only?

[Andi Gutmans]

At 12:12 PM 2/28/2003 -0500, Ilia A. wrote:
On February 28, 2003 11:50 am, George Schlossnagle wrote:
> #php.bugs seems to be invite only now.  How do I go about getting
> myself invited?
It would appear someone had accidentaly set the channel to invite only, it is
fixed now.
I mailed Jani with the same question :)

Andi

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

Re[2]: [PHP-DEV] Weak references in PHP

[Andi Gutmans]

At 08:00 PM 2/28/2003 +0300, Konstantin Knizhnik wrote:
Hello Andi,

The problem is that script can fetch very large number of objects
and all of them doesn't fit in the memory. Lets say we have very
large list of objects (several millions objects or more). And our
script traverse the list and fetch objects one by one and do some
calculations (for example calculates total sum). So at each moment of
time only one persistent object is actually needed. But without weak
references we will have to keep all these millions of objects in
memory.
If you need to go over a list of million objects you are doing something 
wrong :)


Also performance of OODBBS greatly depends on efficient
caching of objects. If we throw away all objects after each request
and has to reload them from the server for each request, then
performance will we awful. It is very significant to be able to cache
most frequently used objects. LRU or some other discipline can be
used for it. But any not depending from the discipline we use we need
some  mechanism which allows to map OPIDs to instances and do not
prevent GC from collecting the objects.
I disagree. JDO performs well and doesn't cache the objects as usually 
pessimistic locking is used with it. Of course, if you want to use 
optimistic locking and the nature of your application allows you to do so 
efficiently the caching might make sense (or it's mainly a read-only app).


That is why almost all languages with implicit memory
deallocation have some kind of weak references. And I was wondered
when do not find such facility in PHP.
Using __destruct method (thanks to George) it may be possible to implement
what I need, but only if object cache is implemented in C (and so is
not visible for PHP garbage collector). So no pure PHP solution exits.
Unfortunately I didn't fins any reference to __destruct method in PHP
manual and do not understand how it works. If I just declare
__destruct method in class, it is not invoked when object is
destructed.
I don't quite understand why you need __destruct() as other systems in Java 
don't use this but I might be completely misunderstanding what you want to do.
Yes, you'll need to do this with a C extension.
Anyway, good luck. I hope the Engine 2 solves some of your problems (such 
as object handles which allow you to always access the same DB object).
Andi

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

Re: [PHP-DEV] ZE2 constructors

[Andi Gutmans]

The patch look OK. Go ahead and commit it.
Andi
At 08:20 PM 2/28/2003 +0100, Marcus Börger wrote:
Hi Zeev,

according to the plans the following test file should PASS:


--TEST--
The new constructor/destructor is called
--SKIPIF--

--FILE--


class early {
function early() {
echo "early::early\n";
}
function __construct() {
echo "early::__construct\n";
}
function __destruct() {
echo "early::__destruct\n";
}
}
class late {
function __construct() {
echo "late::__construct\n";
}
function late() {
echo "late::late\n";
}
function __destruct() {
echo "late::__destruct\n";
}
}
$t = new early();
$t->early();
unset($t);
$t = new late();
$t->late();
//unset($t); delay to end of script
echo "Done\n";
?>
--EXPECTF--
early::__construct
early::early
early::__destruct
late::__construct
late::late
Done
late::__destruct
#
However it fails and this patch is needed which also fixees the last final 
problem
mentioned already:

#
Index: Zend/zend_compile.c
===
RCS file: /repository/ZendEngine2/zend_compile.c,v
retrieving revision 1.375
diff -u -r1.375 zend_compile.c
--- Zend/zend_compile.c 25 Feb 2003 10:03:26 -  1.375
+++ Zend/zend_compile.c 28 Feb 2003 19:14:52 -
@@ -916,6 +916,9 @@
&& ((current_access_type->u.constant.value.lval & 
ZEND_ACC_PPP_MASK) != (new_modifier->u.constant.value.lval & 
ZEND_ACC_PPP_MASK))) {
zend_error(E_COMPILE_ERROR, "Multiple access type 
modifiers are not allowed");
}
+   if (((current_access_type->u.constant.value.lval | 
new_modifier->u.constant.value.lval) & (ZEND_ACC_ABSTRACT | 
ZEND_ACC_FINAL)) == (ZEND_ACC_ABSTRACT | ZEND_ACC_FINAL)) {
+   zend_error(E_COMPILE_ERROR, "Cannot use the final modifier 
on an abstract class member");
+   }
if (((current_access_type->u.constant.value.lval | 
new_modifier->u.constant.value.lval) & (ZEND_ACC_PRIVATE | 
ZEND_ACC_FINAL)) == (ZEND_ACC_PRIVATE | ZEND_ACC_FINAL)) {
zend_error(E_COMPILE_ERROR, "Cannot use the final 
modifier on a private class member");
}
@@ -974,7 +977,7 @@
fn_flags |= ZEND_ACC_PUBLIC;
}

-   if ((short_class_name_length == name_len) && 
(!memcmp(short_class_name, name, name_len))) {
+   if ((short_class_name_length == name_len) && 
(!memcmp(short_class_name, name, name_len)) && 
!CG(active_class_entry)->constructor) {
CG(active_class_entry)->constructor = 
(zend_function *) CG(active_op_array);
} else if ((function_name->u.constant.value.str.len == 
sizeof(ZEND_CONSTRUCTOR_FUNC_NAME)-1) && 
(!memcmp(function_name->u.constant.value.str.val, 
ZEND_CONSTRUCTOR_FUNC_NAME, sizeof(ZEND_CONSTRUCTOR_FUNC_NAME {
CG(active_class_entry)->constructor = 
(zend_function *) CG(active_op_array);
#

regards
marcus


--
--
Marcus Börger - Looking for all sorts of freelance work - just ask...
Did i help you? Consider a gift:
http://www.amazon.de/exec/obidos/wishlist/ho722v0rg1u0
--


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

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

[Andi Gutmans]

At 11:03 PM 3/4/2003 +0100, Sascha Schumann wrote:
On Tue, 4 Mar 2003, Jani Taskinen wrote:

>
> Yup, that was the idea. I'll first change them
> all to OnUpdateInteger, and then use your patch
> to change the ones that need to be long to use OnUpdateLong.
Is there any specific reason why a single API (OnUpdateLong)
is not sufficient?  Is not it a safe assumption that those
modules which still use 'int's are simply the result of a
mistake on the developer's side?
A single API is probably sufficient but I can understand that extension 
writers might want to use ints. The INI flag might have nothing to do with 
an internal zval and an int might be more than enough.
I don't really mind but I wouldn't introduce OnUpdateInteger.
I guess we should either move everything to OnUpdateLong() and nuke 
OnUpdateInt() in ZE2 or we change OnUpdateInt to work with ints and fix the 
whole code.
It might be less confusing to just have one.
Andi

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

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

[Andi Gutmans]

At 01:29 PM 3/5/2003 +0800, James Devenish wrote:
In message <[EMAIL PROTECTED]>
on Wed, Mar 05, 2003 at 07:24:20AM +0200, Andi Gutmans wrote:
> It might be less confusing to just have one.
Hasn't worked so far ;)
Well we're talking about changing the name from OnUpdateInt to 
OnUpdateLong. It should reduce confusion.

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

Re: [PHP-DEV] [patch] solaris getcwd() brokeness

[Andi Gutmans]

I think the patch is OK. I'm not extremely happy with it because I don't 
think it's very beautiful but I didn't have time to think of a better way 
of fixing it.
I think he can go ahead and commit it but I'd like there to be comments in 
the source code to explain why those checks on state->cwd_length are being 
made. This will help ppl understand this weirdness later on...

Andi

At 04:38 PM 3/10/2003 +0200, Jani Taskinen wrote:

Andi, what's the status with this?

--Jani

On Sun, 23 Feb 2003, Wez Furlong wrote:

>Hi Andi (and James)
>
>Andi: I'd appreciate your comments on this patch, specifically if there
>are any concerns about it doing the right thing.
>
>Most people here:
>http://bugs.php.net/bug.php?id=21310&edit=1
>
>report that it fixes their problems with solaris.
>
>I've held off from looking at this, as I didn't want to duplicate any
>effort you have been making.
>
>--Wez.
>
>On Sun, 16 Feb 2003, Andi Gutmans wrote:
>
>> At 03:41 PM 2/13/2003 -0500, James E. Flemer wrote:
>> >RCS file: /repository/TSRM/tsrm_virtual_cwd.c,v
>> >retrieving revision 1.41
>> >diff -u -b -r1.41 tsrm_virtual_cwd.c
>> >--- TSRM/tsrm_virtual_cwd.c 6 Nov 2002 18:07:22 -   1.41
>> >+++ TSRM/tsrm_virtual_cwd.c 13 Feb 2003 20:40:07 -
>> >@@ -303,7 +303,7 @@
>> > return (0);
>> >
>> >  #if !defined(TSRM_WIN32) && !defined(NETWARE)
>> >-   if (IS_ABSOLUTE_PATH(path, path_length)) {
>> >+   if (IS_ABSOLUTE_PATH(path, path_length) || (state->cwd_length 
< 1)) {
>> > if (use_realpath && realpath(path, resolved_path)) {
>> > path = resolved_path;
>> > path_length = strlen(path);
>>
>> Will realpath() work in cases where getcwd() didn't work? (btw it's nicer
>> to check state->cwd_length == 0 than < 1 IMO).
>>
>> >@@ -363,6 +363,7 @@
>> > }
>> >
>> >
>> >+  if (state->cwd_length > 0 || IS_ABSOLUTE_PATH(path, path_length)) {
>> > ptr = tsrm_strtok_r(path_copy, TOKENIZER_STRING, &tok);
>> > while (ptr) {
>> > ptr_length = strlen(ptr);
>> >@@ -416,6 +417,11 @@
>> > state->cwd[state->cwd_length+1] = '\0';
>> > state->cwd_length++;
>> > }
>> >+  } else {
>> >+   state->cwd = (char *) realloc(state->cwd, path_length+1);
>> >+   memcpy(state->cwd, path, path_length+1);
>> >+   state->cwd_length = path_length;
>> >+  }
>>
>> I'm trying to think if there's some other way of doing this. What is the
>> main problem in this loop? Does it add  / or c:\ in the beginning of the
>> string?
>>
>> Andi
>>
>>
>> --
>> PHP Development Mailing List <http://www.php.net/>
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>>
>
>
>

--
<- For Sale! ->


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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /tests/classes interface_class.phpt interface_doubled.phpt interface_implemented.phpt interface_instantiate.phpt interface_member.phpt interface_method.phpt interface_method_final.phpt interface_method_private.phpt interface_must_be_implemented.phpt

[Andi Gutmans]

At 08:53 AM 3/12/2003 -0500, Andrei Zmievski wrote:
I have 2 questions:

1. Do the interface functions have to be explicitly specified as
abstract?
Nope. It shouldn't be allowed to be abstract because it's abstract by 
definition.


   interface Foo {
function bar();
   }
Because this runs fine for me with no errors.

1. What is the difference between the following:

   interface Foo {
   }
   class Boo extends Foo {
   }
This shouldn't work. I guess there's a bug someplace. It's new code so I'm 
sure there will be some small things which need to be fixed.
Andi

and

   class Zoo implements Foo {
   }
-Andrei   http://www.gravitonic.com/

"In this age, which believes that there is a short cut to everything,
 the greatest lesson to be learned is that the most difficult way is, in
 the long run, the easiest."
-Henry Miller, The Books in My Life
--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php


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

Re: [PHP-DEV] Moderate PHP-DEV

[Andi Gutmans]

This discussion itself is creating more spam than those emails people send.
I agree with Sascha that we shouldn't take drastic measures. We still want 
to make it easy for people to join the PHP developer's community.
I think the most interesting idea so far was Shane's first post response 
system. We have all of the necessary infra-structure ready.
Hopefully we can reach an agreement ASAP because I can't handle all of 
these emails anymore :)

Andi

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

[PHP-DEV] Newbie developer's information

[Andi Gutmans]

At 04:17 PM 3/12/2003 -0500, David Hill \(php.net\) wrote:
As a newbie commiter, still wet behind the ears, I would have *really*
appreciated a page that was a little clearer and a bit more up to date
than what I started with. My sources of information README.CVS-RULES,
the building from cvs web page) were very good, but missed some vital
clues. While many have been very patient with me (thanks), I found it
frustrating to ask questions that seem to be obvious to others 
like:
* trying to build php4 head for two days, only to be told that I
should be building PHP_4_3 or php5 head.
* forgetting about re2c, which is not mentioned anywhere that I could
find, but I found through freshmeat and had a lovely time trying to
build :-)
I am taking note of the problems I encountered and was planning on
updating something (README.CVS-RULES ?) after another week or so.
Improvements would be welcome. I'm not sure where the best place would be. 
Maybe on the web site?

Andi

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

Re: [PHP-DEV] Moderate PHP-DEV

[Andi Gutmans]

At 11:01 PM 3/12/2003 +0100, Sascha Schumann wrote:
> I wouldn't consider 3rd one that drastic.
> It has worked very well for me, I haven't got any spam
> to my php.net addy, but people who really wanted to send me
> email got through..
Well, maybe I am an exception, but I usually don't bother to
"register" myself anywhere, unless there is a really good
reason.  Thus, the proposed measure increases the bar for
contributions significantly.
We don't lose anything by giving the first two items some
time to prove their usefullness.  On the other hand, it is
very likely that we will lose useful input, if we implement
the third item prematurely.
I disagree. Anyone here can handle replying because we already have the 
anti-spam protection. The only thing we're doing is adding to the message 
an explanation of the post ethics.
I wouldn't call this drastic at all.

Andi

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

RE: [PHP-DEV] Possible problem in the parser

[Andi Gutmans]

You are right that it doesn't behave the same as C. However, personally 
although it might have been better for it to work like C I don't think it's 
a good idea to change it now. First of all it would break backwards 
compatibility in a way which would be hard for people to find where the bug 
is and how to fix it. Secondly, not meaning to insult anyone here, but I 
think people who write such code without using parentheses should improve 
their coding style :)

Andi

At 12:01 PM 3/14/2003 +, Ford, Mike   [LSS] wrote:
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: 13 March 2003 19:33
> To: Ford, Mike [LSS]
> Cc: 'Andrey Hristov'; [EMAIL PROTECTED]
> Subject: RE: [PHP-DEV] Possible problem in the parser
>
>
> At 14:58 13.03.2003, Ford, Mike   [LSS] wrote:
>
> >Just to make this completely clear, in left-associative PHP
> >
> >b = a==1? 4:a==2? 5:6;
> >
> >is equivalent to
> >
> >b = (a==1? 4:a==2)? 5:6;
>
>
> NO it is not equal. Either '==' has higher precedence OR '?:' has.
> See one of my previous mails where i showed where the error is.
Yes, it is -- believe me, I've researched this extensively.  It is NOT 
about precedence, but associativity.  If you want me to be totally 
completist about this:

Starting from:

   b = a==1? 4:a==2? 5:6;

precedence rules make this equivalent to:

   b = (a==1)? 4:(a==2)? 5:6;

but this is still ambiguous -- which ?: phrase do you evaluate 
first?  Associativity provides the answer: in PHP, where ?: is left 
associative (i.e. the left most ?: is evaluated first), the result is 
equivalent to:

   b = ((a==1)? 4:(a==2))? 5:6;

On the other hand, in c, where ?: is right associative, the equivalent is:

   b = (a==1)? 4:((a==2)? 5:6);

which, apart from the additional (unnecessary) parentheses around the == 
comparisons, is exactly what I said before.

QED

Cheers!

Mike

-
Mike Ford,  Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Beckett Park, LEEDS,  LS6 3QS,  United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730  Fax:  +44 113 283 3211
--
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php


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

Re: [PHP-DEV] Pb : access control

[Andi Gutmans]

Can you cut down the script to like 10 lines and say what your result is 
and what you'd expect?

At 05:37 PM 3/17/2003 +0100, Fabrice Le Coz wrote:
Hi,

I'm playing with PHP5 and have some trouble wtith access control, here's the
code I run with last php5 from snaps.php.net under windows XP :

function __construct() {
$this->var1 = "public";
$this->var2 = "protected";
$this->var3 = "private";
}
function show() {
echo "pere::show() \n";
echo "var1 : $this->var1\n";
echo "var2 : $this->var2\n";
echo "var3 : $this->var3\n";
echo "\n";
}
}
class fils extends pere {
protected $var = "fils";
private   $var4 = "test";
function __construct() {
parent::__construct();
}
function show_fils() {
echo "fils::show() \n";
echo "var1 : $this->var1\n";
echo "var2 : $this->var2\n";
echo "var3 : $this->var3\n";
echo "var  : $this->var\n";
echo "\n";
}
}
function show_var($obj) {
$obj_vars = get_object_vars($obj);
foreach ($obj_vars as $name => $value) {
if($name != "") echo "$name : $value\n";
}
echo "\n";
}
$test1 = new pere();
$test1->show();
echo "Affichage des variables visibles de test1 :\n";
show_var($test1);
$test2 = new fils();
$test2->show_fils();
echo "Affichage des variables visibles de test2 :\n";
show_var($test2);
$test2->show();
echo "var3 : ".$test2->var3."\n";
echo "var4 : ".$test2->var4."\n";
?>
and I've the following result :

pere::show()
var1 : public
var2 : protected
var3 : private
Affichage des variables visibles de test1 :
var1 : public
fils::show()
var1 : public
var2 : protected
var3 : private
var  : fils
Affichage des variables visibles de test2 :
var1 : public
var2 :
var3 : private
pere::show()
var1 : public
var2 : protected
var3 : private
var3 : private

Fatal error: Cannot access private property fils::$var4 in
D:\www\test\heritier.php on line 59
Normally in the instance of "fils" object ($test2), I mustn't see
$this->var3 which is private variable of the parent. if I comment the line
'echo "var3 : $this->var3\n";' in the show_fils method, $test2->var3 is
empty but do not generate an error !
The show_var($test2) function expose a var2 variable which normally must
send an Fatal error.
Fabrice Le Coz
[EMAIL PROTECTED]


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


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

RE: [PHP-DEV] Re: [Zend Engine 2] RE: [PHP-DEV] REPOST: Class Autoloading [PATCH]

[Andi Gutmans]

At 06:24 PM 8/7/2002 +0200, phpsurf wrote:
>Hi
>
>I'm testing this great feature ...
>but unfortunately, it lokos like it doesn't work for extended classes either
>!
>
>in brad's example (in the history of this mail)
>you cannot remove the include_once statements in the children classes (I
>would rather replace them with the apropriate call to the __autoload
>function)
>
>the class MyFoo extends Foo
>when you try to instantiate Foo, __autoload works perfectly.
>but when you try to instantiate MyFoo, it fails with the following message:
>"Fatal error: Class myfoo: Cannot inherit from undefined class foo in
>c:\webroot\ze2\myfoo.php on line 2"
>
>andi ? is it not supposed to work either with extended classes ?

Can you please send me a very short script which reproduces your problem?

Thanks,

Andi

> > -Original Message-
> > From: Andi Gutmans [mailto:[EMAIL PROTECTED]]
> > Sent: mercredi 26 juin 2002 21:02
> > To: Brad LaFountain; Ivan Ristic; phpsurf
> > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> > Subject: Re: [PHP-DEV] Re: [Zend Engine 2] RE: [PHP-DEV] REPOST: Class
> > Autoloading [PATCH]
> >
> >
> > Hey,
> >
> > What I meant was nested classes, my bad :)
> > I meant it won't work for Foo::Bar::Barbara but only for class Foo.
> >
> > Andi
> >
> > At 11:56 AM 6/26/2002 -0700, Brad LaFountain wrote:
> > > > - will never work for sub-classes so don't even ask!
> > >
> > >Andi,
> > >
> > >  This doesn't need to be an issue. The way that I use
> > sub-classes is I ALWAYS
> > >include_once("subclass.php"); at the top of each superclass file. I know
> > >everyone doesn't code the same way but maybe you can have that
> > as a suggestion
> > >to people who use __autoload.
> > >
> > >Foo.php
> > >class Foo{}
> > >
> > >Bar.php
> > >class Bar{}
> > >
> > >MyFoo.php
> > >include_once("Foo.php");
> > >class MyFoo extends Foo{}
> > >
> > >MyBar.php
> > >include_once("Bar.php");
> > >class MyBar extends Bar{}
> > >
> > >
> > >auto_test.php
> > > > >function __autoload($name) {
> > >  include_once("$name.php");
> > >}
> > >$f = new MyFoo();
> > >$b = new MyBar();
> > >?>
> > >
> > >- brad
> > > >
> > > > At 11:27 PM 6/11/2002 +0100, Ivan Ristic wrote:
> > > > > > Okay, I guess I can live with it :)
> > > > > >
> > > > > > Andi
> > > > >
> > > > >   Is there anyone else who would like to comment on the
> > > > >   patch?
> > > > >
> > > > >   http://www.webkreator.com/download/class_autoload.patch
> > > > >
> > > > >   Or can we have it committed?
> > > > >
> > > > >--
> > > > >Ivan Ristic, [EMAIL PROTECTED]
> > > > >[ Weblog on PHP, Software development, Intranets,
> > > > >and Knowledge Management: http://www.webkreator.com ]
> > > > >
> > > > >
> > > > >--
> > > > >PHP Development Mailing List <http://www.php.net/>
> > > > >To unsubscribe, visit: http://www.php.net/unsub.php
> > > >
> > > >
> > > > --
> > > > PHP Development Mailing List <http://www.php.net/>
> > > > To unsubscribe, visit: http://www.php.net/unsub.php
> > > >
> > >
> > >
> > >__
> > >Do You Yahoo!?
> > >Yahoo! - Official partner of 2002 FIFA World Cup
> > >http://fifaworldcup.yahoo.com
> >
> >
> > --
> > PHP Development Mailing List <http://www.php.net/>
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
>
>__
>i (france), c'est aussi une gamme complète de PC en exclusivité avec DELL
>http://www.ifrance.com/_reloc/signedell


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

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

[Andi Gutmans]

I also think we should make sure enough people have motivation to move to 
ZE2. If not it'll be hard to push it out and we all know that it's a very 
important step for PHP. As it is, there is still not enough momentum behind it.
Andi

At 05:38 PM 8/18/2002 +0300, Zeev Suraski wrote:
>I said before - I prefer not having any changes in ZE1, for both stability 
>reasons and also as a motivation to get ZE2 out the door more quickly.
>
>Zeev
>
>At 17:21 18/08/2002, Thies C. Arntzen wrote:
>
>> if noone objects i'm going to commit this to -HEAD (and we
>> can start discussing it then;-)
>>
>> re,
>> tc
>>
>>On Fri, Aug 16, 2002 at 07:39:59PM +0200, Thies C. Arntzen wrote:
>> >
>> > hi,
>> >
>> > this patch adds the extremely useful debug_backtrace()
>> > function to ZE1.  as it's more-or-less the same
>> > implementation as in ZE2 so it should be "fast and efficient"
>> > enough for inclusion in 4.3 IMHO.
>> >
>> > it has one extra feature over the ZE2 implementation by
>> > giving some extra information if a method was called
>> > using :: or -> (see the 'type' attribute in the array
>> > returned by debug_backtrace).
>> >
>> > zeev, andi one question: i had to comment line 1628 (just
>> > apply the patch and see for yourself) to make the following
>> > code work correctly (= show the class in the backtrace):
>> >
>> > > > class a {
>> >   function dump() {
>> >   var_dump(debug_backtrace());
>> >   }
>> > }
>> >
>> > $a = new a;
>> > $a->dump();
>> > ?>
>> >
>> > (just uncomment line 1628 in the patched sources and see how
>> > the output of debug_backtrace doesn't show the class-name for
>> > this script any more)
>> >
>> > i don't think that commenting this line will have any
>> > side-effect as EG(object).ptr will be re-initialized in 1665
>> > and i don't see any references to it in between.
>> >
>> > i'd love to have this included in 4.3.0 and i think a lot of
>> > people would be happy as well.
>> >
>> > implementation:
>> > to make this whole thing work i simply added the class_entry
>> > to the execute_data and am pushing and popping it together
>> > with (object).ptr.
>> >
>> > if this patch gets accepted i'll add an php.ini seting so
>> > that errors and warnings will optionally have the full
>> > call-stack.
>> >
>> >
>> > comments are welcome - especially from andi & zeev.
>> > tc
>> >
>> > PS: patch is against -HEAD
>> >
>> > --
>> > Thies C. Arnzten   -   Looking for all sorts of freelance 
>> work  -   just ask..
>> > Whishlist: 
>> http://www.amazon.de/exec/obidos/wishlist/AB9DY62QWDSZ/ref=wl_em_to
>>
>> > ? ext/tca_prof
>> > Index: Zend/zend_builtin_functions.c
>> > ===
>> > RCS file: /repository/Zend/zend_builtin_functions.c,v
>> > retrieving revision 1.118
>> > diff -u -r1.118 zend_builtin_functions.c
>> > --- Zend/zend_builtin_functions.c 12 Jun 2002 17:02:22 
>> -  1.118
>> > +++ Zend/zend_builtin_functions.c 16 Aug 2002 17:22:01 -
>> > @@ -65,6 +65,7 @@
>> >  static ZEND_FUNCTION(extension_loaded);
>> >  static ZEND_FUNCTION(get_extension_funcs);
>> >  static ZEND_FUNCTION(get_defined_constants);
>> > +static ZEND_FUNCTION(debug_backtrace);
>> >  #if ZEND_DEBUG
>> >  static ZEND_FUNCTION(zend_test_func);
>> >  #endif
>> > @@ -116,6 +117,7 @@
>> >   ZEND_FE(extension_loaded,   NULL)
>> >   ZEND_FE(get_extension_funcs,NULL)
>> >   ZEND_FE(get_defined_constants,  NULL)
>> > + ZEND_FE(debug_backtrace,NULL)
>> >  #if ZEND_DEBUG
>> >   ZEND_FE(zend_test_func, NULL)
>> >  #endif
>> > @@ -1133,6 +1135,69 @@
>> >   array_init(return_value);
>> >   zend_hash_apply_with_argument(EG(zend_constants), 
>> (apply_func_arg_t) add_constant_info, return_value TSRMLS_CC);
>> >  }
>> > +
>> > +/* {{{ proto void debug_backtrace(void)
>> > +   Prints out a backtrace */
>> > +ZEND_FUNCTION(debug_backtrace)
>> > +{
>> > + zend_execute_data *ptr;
>> > + int lineno;
>> > + char *function_name;
>> > + char *filename;
>> > + char *class_name;
>> > + zend_uint class_name_length;
>> > + zval *stack_frame;
>> > +
>> > + ptr = EG(execute_data_ptr);
>> > +
>> > + /* Skip debug_backtrace() itself */
>> > + ptr = ptr->prev_execute_data;
>> > +
>> > + array_init(return_value);
>> > +
>> > + while (ptr) {
>> > + MAKE_STD_ZVAL(stack_frame);
>> > + array_init(stack_frame);
>> > +
>> > +
>> > +/*   if (ptr->object) {
>> > + class_name = Z_OBJCE(*ptr->object)->name;
>> > + class_name_length = 
>> Z_OBJCE(*ptr->object)->name_length;
>> > + }
>> > + if (ptr->function_state.function->common.scope) {
>> > + class_name = 
>> ptr->functio

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

[Andi Gutmans]

At 07:50 PM 8/18/2002 +0200, Thies C. Arntzen wrote:
>On Sun, Aug 18, 2002 at 10:29:47AM -0700, Rasmus Lerdorf wrote:
> > I don't think we should stop people from tweaking ZE1. ZE2 is probably
> > more than a year away from realistically being available to a lot of
> > people. It takes a while for people to upgrade, and many will skip the .0
> > release.  If a few tweaks to ZE1 can eliminate peoples' motivation to move
> > to ZE2, then why are you writing ZE2?  I obviously don't think that is the
> > case as ZE2 has a number of features people have been asking for.
>
> i (of course) agree with derick and rasmus. i'm all for
> applying the patch as is. if zeev and andi don't want to
> comment on it for their own reasons i cannot help them. if
> the patch has a problem it'll be found very soon and it'll
> be fixed.

This isn't a conspiracy but I just completely forgot about your Email. 
Obviously if it is decided that this patch goes into Engine 1 I will look 
it over. The last thing I'd do was to allow a buggy patch to enter the Engine.


> if there is any *technical* reason why this patch is "not as
> good" as the debug_backtrace that is in ZE2 - let me know.
> otherwise i'll commit on monday.

I don't think that there are any big technical reasons not to include the 
patch although it might be a bit buggy though as it hasn't been tested very 
extensively.

I do think you guys should consider the psychological aspects of starting 
to back port my patches from Engine 2.
I personally think that the ZE2 is essential for PHP to prosper in the next 
few years. The only way it can be pushed is if not only Zeev and I but 
other people in the community help push it too. It was mentioned that there 
are a couple of things still missing. I can sum it up that the two main 
features which are missing are some inheritence problems with nested 
classes, private methods and a delegation mechanism which was discussed on 
engine2 for which came up with a pretty decent way of doing which stays 
with the PHP spirit. These things will be implemented and there is no 
reason to wait until they are fully implemented in order to start pushing 
things a bit more. I started with a couple of alpha's and I definitely want 
to go for another one soon as I fixed some bugs.

In the same way we didn't back port some ideas from PHP 4 to PHP 3 I think 
it's best not to do it now. Because in the end, once we (php-dev) 
transitions to ZE2 our support will naturally start shifting more and more 
towards the latest versions (the same as it did in the PHP 3 -> PHP 4 
transition). After sometime people on php-dev just won't feel like working 
on old stuff anymore. Therefore, I think we should make the benefit of 
transition to ZE2 as great as possible so that people migrate.
As to the comparison to Apache 2 I think you're far off. The PHP 3 -> PHP 4 
transition was much smoother than that and the ZE1 -> ZE2 transition isn't 
even between rewrites but just improvements over the old stable version. 
Once a significant amount of people use it I think it'll take 2-3 months to 
iron out the bugs.

Andi


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

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

[Andi Gutmans]

At 09:55 PM 8/19/2002 -0700, Brad LaFountain wrote:
> > I still think it shouldn't go in.  This is the only feature in Engine 2
> > which might make non-OOP people convert. Once this isn't in Engine 2 we
> > don't have a carrot for them.
>
>  You as a Zend owner who's business could be very propitable for Zend2 
> success
>or you as a php developer, think that debug_backtrace is bad for php. 
>Sometimes
>I think that your and zeev's ideas are more business oriented than better for
>the php community. I'm sure im wrong but thats the way it seems from where I
>sit.
>  I think that Thies is right he's not trying to back port all of the zend2
>functionality but debug_backtrace should have been in many years ago. Holding
>back such an important feature just so more people would move to zend2 isnt
>going to make zend2 more popular but I think it doesn't move php forward at
>all. I would like to see everyone to move to zend2 but we all know that isn't
>going to happen with our without including debug_backtrace to zend1, php4 
>isn't
>going to go away as easy as php3 did no matter how big the carrot is.
>
> > Why can't you respect this way of thinking? Especially as I wrote the 
> code?
> > You're basically saying screw them because I'll commit it anyway.
>
>  I think he should commit it anyways. He isn't disrespecting you he just 
> feels
>strongly against you (as do alot of others). Sometimes I don't think you
>respect their way of thinking.
>
>  Sorry if this email sounds like its attacking you. It isn't intended to.

Hey,

The reason for my objection is not business oriented whatsoever. I did 
witness the transitions from PHP/FI 2 -> PHP 3 (ZE 0.5) and PHP 3 -> PHP 4. 
The first transition wasn't too difficult although there were quite a lot 
of BC issues because the user base wasn't too big. The PHP 3 -> PHP 4 
transition was actually quite hard. It took us a long time to get php-dev@ 
moving on the new version because most of them were still using PHP 3 for 
their production sites.
The fact that you guys are so strongly in favor of putting this cool 
feature into ZE1 proves that not putting it in could give ZE2 a big boost 
of momentum. Everyone feels very strongly about this feature. (On a side 
note, at least that makes me happy that people liked this 
revolutionary/negligible performance impact patch :)

I think we need this new momentum. A new version of the engine is very 
important if we want PHP to compete with the latest technologies. If PHP 
doesn't get moving on its next version I'm afraid it won't be able to 
maintain its current position in the market.
The only person I have seen thinking of what he'd like to get done for PHP 
5 is Wez.
By the way, the only personal gain I have in getting ZE2 out of there is 
that it's my code and that PHP will do much better. I think that PHP is 
going to loose out big time if things don't start gaining some momentum. 
Backporting is definitely a momentum breaker *especially* as everyone 
really really wants to backport it badly. That's exactly my point. If you 
guys want it so badly then work for it! :)

Andi


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

Re: [PHP-DEV] PATCH: debug_backtrace() function for 4.3-dev/ZE1

[Andi Gutmans]

At 11:20 AM 8/20/2002 -0700, Rasmus Lerdorf wrote:
> > By the way, the only personal gain I have in getting ZE2 out of there is
> > that it's my code and that PHP will do much better. I think that PHP is
> > going to loose out big time if things don't start gaining some momentum.
> > Backporting is definitely a momentum breaker *especially* as everyone
> > really really wants to backport it badly. That's exactly my point. If you
> > guys want it so badly then work for it! :)
>
>Andi, everybody reading this list can rather simply patch it in
>themselves. At least, I already have. It's not us we are talking about
>here, it is the general user population. This is a patch that helps users
>now. That's what is important.
>
>Us, the developers of php-dev, will move to php5 at the same rate
>regardless of this patch.  And when the developers move to php5 the users
>will invariably follow as they start to see all the support shifting to
>that version.

I'm also starting to get tired so I'll make this my last Email (hopefully).
I emailed Thies in private about this issue and I have a feeling he'll 
commit the patch.
I just want to summarize a few points I wrote him:
I see adding debug_backtrace() to ZE1 tactical thinking. I think postponing 
it to ZE2 is strategic thinking. It's not to do with who wants to help PHP 
users more, but how we think we'll manage to help them more. Obviously as 
the person who wrote the patch all my intention was to help the average PHP 
user.
The current mood on php-dev is "it'll take years for PHP 5 to be released 
so let's add it". I think if everyone here would work hard on it we could 
get it out within about 4 months. That would only happen if ppl were to 
write less Emails and do more organizing and coding though. Unlikely... PHP 
4.3 has been lingering forever. We could have released PHP 5 in this time. 
Okay, I still have a couple of things on my ZE2 todo but they could have 
been slipped in gradually while the rest get their stuff ready.

Personally, I think it's time to help PHP keep up with its competitors. I 
think we should invest our energy in that.
debug_backtrace() was the wake-up call to remind ppl to look into the future.

Let's just keep it at that because I'm getting tried and prefer working on 
useful stuff like working on the next version of PHP.
Andi


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

Re: [PHP-DEV] Streams filter API

[Andi Gutmans]

At 10:47 PM 8/20/2002 +0100, Wez Furlong wrote:
>Filters are created using:
>   php_stream_filter_create(char *filtername, char *filterparams,
> int filterparamslen, int persistent TSRMLS_DC);
>
>filtername corresponds to the name used to register the factory;
>if no exact match is found, it looks for a factory matching
>".*", and then passes the filtername to it's factory method.
>
>Filterparams is a binary safe string parameter which can carry
>some kind of options to a filter implementation.  For example,
>it might specifit the compression level for a zlib filter, or it
>might control the number of bits used in a cypher, or some kind
>of key for cypto filters.
>The filter API doesn't touch this parameter; it's interpreted only
>by the factory object/method.

Hey,

I think it's probably best to make filterparams a void * because then you 
can pass whatever you want (a structure with all the params and so on). Of 
course you can do it with your current prototype too but this is how it's 
usually done.
I haven't looked into the API itself so if it doesn't make much sense 
ignore me :)

Andi


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

Re: [PHP-DEV] friendly classes

[Andi Gutmans]

At 10:59 AM 8/21/2002 +0100, Tom Oram wrote:
>Hi,
>I'm currenly looking at/doing a lot of object orientated PHP so I have been
>looking into what new features Zend 2 will offer me. I have just run into a
>situation where if I was using Zend 2 I would need some sort of implementation
>of C++ friends, I'm not to sure about the java alternative (is it package
>access?). Anyway is this consept likely to appear in PHP at any time?

I wouldn't want to get into what I consider "the ugly sides of C++'s OOP".
If you need friend then just go ahead and make it public :)

Andi


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

Re: [PHP-DEV] Possible leak in zend_llist ?

[Andi Gutmans]

Hey,

I think you're right. Someone changed this code a while ago and might have 
introduced this problem (or it was like this before).
I commited a fix and hope it doesn't break anything :)
If anyone uses llist's please make sure it's OK.

Andi

At 07:30 AM 8/27/2002 -0400, l0t3k wrote:
>hi,
>  im reviewing the source code of zend_llist.c and it appears there may be an
>inconsistency in the way deletions are handled which may cause leaks.
>   in particular the macro DEL_LLIST_ELEMENT only releases memory for a node
>if a destructor is specified for the zend_llist, whereas memory is always
>allocated for the node when an insert is performed.
>this macro is used only in zend_llist_apply_with_del and
>zend_llist_del_element. note that
>no other code in the file assumes that the destructor function is
>responsible for the deallocation of the _node_
>
>compare DEL_LLIST_ELEMENT (snippet)
>
>if ((l)->dtor) {\
> (l)->dtor((current)->data);\
> pefree((current), (l)->persistent);\
>}\
>
>with zend_llist_destroy
>
>   if (l->dtor) {
>l->dtor(current->data);
>   }
>   pefree(current, l->persistent);
>
>
>l0t3k
>
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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

Re: [PHP-DEV] ISAPI Crash Debugging Notes

[Andi Gutmans]

Any chance you can setup and Engine 2 build and see if this problem persists?

Andi

At 06:42 AM 8/27/2002 -0700, Michael Sisolak wrote:

>--- Zeev Suraski <[EMAIL PROTECTED]> wrote:
> > At 09:53 27/08/2002, Michael Sisolak wrote:
> > > > >i've been doing some debugging of the crashes when running php
> > under
> > > > >the isapi sapi.  is anybody else currently looking at this?  if
> > you
> > > > >are let's talk - here are my notes so far.
> > > >
> > > > first off, can you try using
> > > > http://www.php.net/~zeev/php-4.2.3rc1.tar.gz
> > > > and see if you experience the same problems?  i've made some
> > > > thread-safety related fixes there, even though none should lead
> > > > to a hard crash...
> > >
> > >zeev,
> > >
> > >i believe that i may have tracked down a major isapi filter
> > >thread-safety hole.  if i understand  what zend_startup() is doing
> > >correctly, it assumes that the thread that it runs under will not
> > also
> > >be used to serve http requests.
> >
> > No, the startup thread can be used as a regular HTTP thread, nothing
> > in the
> > code should prevent that.
> > The globals code in the startup sequence is very tricky, but it
> > should work.
>
>This is a sample of the debug output that I'm seeing (this is PHP 4.2.1
>running under Windows 2000 Professional, single CPU):
>
>[1948] the startup thread is 1956
>[1948] GLOBAL_FUNCTION_TABLE is 4226120
>[1948] in HttpExtensionProc thread 1956, CG(function_table) is 4226120
>[1948] in HttpExtensionProc thread 1520, CG(function_table) is 18834536
>[1948] in HttpExtensionProc thread 920, CG(function_table) is 18838912
>[1948] in HttpExtensionProc thread 1956, CG(function_table) is 4226120
>[1948] in HttpExtensionProc thread 1256, CG(function_table) is 19250808
>[1948] in HttpExtensionProc thread 920, CG(function_table) is 18838912
>[1948] in HttpExtensionProc thread 1956, CG(function_table) is 4226120
>
>Notice that the initial thread (1956) appears to continue to use
>GLOBAL_FUNCTION_TABLE as it's own CG(function_table).  I'm reporting
>the GLOBAL_FUNCTION_TABLE value from within zend_startup() - is there
>some point later in the code that makes it okay that this is the same
>value that I get for a CG(function_table) later?
>
> > Either way - starting threads from an ISAPI filter/extension is
> > completely
> > forbidden (or at least strongly discouraged) so even if there is some
> > bug
> > in there, starting our own thread is not an option.
>
>I don't believe that this is true.  In this sample on MSDN:
>
>http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q197728
>
>their code for GetExtensionVersion calls AfxBeginThread.  Also in this
>document:
>
>http://msdn.microsoft.com/library/en-us/vccore/html/vcconatlserverandcom.asp
>
>point 1 recommends "Create your own thread in GetExtensionVersion on
>which you can initialize COM..."
>
> > Can you give me the data I mentioned in the previous letter?
>
>This is PHP 4.2.1 running under Windows 2000 Professional (SP3) on a
>single CPU system.  I can't really send the code as I'm currently
>testing with a large application that I have been running under CGI.
>I'll see if I can come up with a simpler example that causes the crash,
>but the debug output above would be the same either way.  Please let me
>know if there is anything else I can provide to help in tracking this
>down.
>
>
>Michael Sisolak
>[EMAIL PROTECTED]
>
>
>__
>Do You Yahoo!?
>Yahoo! Finance - Get real-time stock quotes
>http://finance.yahoo.com
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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

Re: [PHP-DEV] adding persistent toggle to zend_stack implementation

[Andi Gutmans]

I think this is fine.

Andi

At 11:32 AM 8/27/2002 -0400, George Schlossnagle wrote:
>Hi,
>
>I'd like to use the zend_stack stuff for stacked handlers in the new 
>apache_hooks sapi stuff, but right now, it emalloc's everything, which is 
>unacceptable for my usage.  I could write my own stack implementation just 
>for the sapi stuf, but thats seems less productive than making zend_stack 
>more universally useable.
>
>I've added a persistent attribute to the struct so that it behaves more 
>like zend_hash, added a zend_stack_init_ex which allows setting of this 
>flag, and #define'd zend_stack_init to do a non-persistent 
>zend_stack_init_ex.  Patches are attached.
>
>If this is somehow undesireable, please let me know and I will just 
>reimplement stacks for sapi.
>
>George
>
>
>
>
>Index: Zend/zend_stack.c
>===
>RCS file: /repository/Zend/zend_stack.c,v
>retrieving revision 1.11
>diff -u -3 -r1.11 zend_stack.c
>--- Zend/zend_stack.c   6 Jan 2002 15:21:09 -   1.11
>+++ Zend/zend_stack.c   27 Aug 2002 15:15:37 -
>@@ -21,10 +21,11 @@
>  #include "zend.h"
>  #include "zend_stack.h"
>
>-ZEND_API int zend_stack_init(zend_stack *stack)
>+ZEND_API int zend_stack_init_ex(zend_stack *stack, int persistent)
>  {
> stack->top = 0;
>-   stack->elements = (void **) emalloc(sizeof(void **) * 
>STACK_BLOCK_SIZE);
>+stack->persistent = persistent;
>+   stack->elements = (void **) pemalloc(sizeof(void **) * 
>STACK_BLOCK_SIZE,  persistent);
> if (!stack->elements) {
> return FAILURE;
> } else {
>@@ -36,13 +37,13 @@
>  ZEND_API int zend_stack_push(zend_stack *stack, void *element, int size)
>  {
> if (stack->top >= stack->max) { /* we need to allocate 
> more memory */
>-   stack->elements = (void **) erealloc(stack->elements,
>-  (sizeof(void **) * (stack->max += 
>STACK_BLOCK_SIZE)));
>+   stack->elements = (void **) perealloc(stack->elements,
>+  (sizeof(void **) * (stack->max += 
>STACK_BLOCK_SIZE)), stack->persistent);
> if (!stack->elements) {
> return FAILURE;
> }
> }
>-   stack->elements[stack->top] = (void *) emalloc(size);
>+   stack->elements[stack->top] = (void *) pemalloc(size, 
>stack->persistent);
> memcpy(stack->elements[stack->top], element, size);
> return stack->top++;
>  }
>@@ -63,7 +64,7 @@
>  ZEND_API int zend_stack_del_top(zend_stack *stack)
>  {
> if (stack->top > 0) {
>-   efree(stack->elements[--stack->top]);
>+   pefree(stack->elements[--stack->top], stack->persistent);
> }
> return SUCCESS;
>  }
>@@ -96,11 +97,11 @@
> register int i;
>
> for (i = 0; i < stack->top; i++) {
>-   efree(stack->elements[i]);
>+   pefree(stack->elements[i], stack->persistent);
> }
>
> if (stack->elements) {
>-   efree(stack->elements);
>+   pefree(stack->elements, stack->persistent);
> }
> return SUCCESS;
>  }
>Index: Zend/zend_stack.h
>===
>RCS file: /repository/Zend/zend_stack.h,v
>retrieving revision 1.13
>diff -u -3 -r1.13 zend_stack.h
>--- Zend/zend_stack.h   6 Jan 2002 15:21:09 -   1.13
>+++ Zend/zend_stack.h   27 Aug 2002 15:15:37 -
>@@ -22,14 +22,14 @@
>  #define ZEND_STACK_H
>
>  typedef struct _zend_stack {
>-   int top, max;
>+   int top, max, persistent;
> void **elements;
>  } zend_stack;
>
>
>  #define STACK_BLOCK_SIZE 64
>-
>-ZEND_API int zend_stack_init(zend_stack *stack);
>+#define zend_stack_init(a) zend_stack_init_ex(a, 0);
>+ZEND_API int zend_stack_init_ex(zend_stack *stack, int persistent);
>  ZEND_API int zend_stack_push(zend_stack *stack, void *element, int size);
>  ZEND_API int zend_stack_top(zend_stack *stack, void **element);
>  ZEND_API int zend_stack_del_top(zend_stack *stack);
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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

Re: [PHP-DEV] ISAPI Crash Debugging Notes

[Andi Gutmans]

At 05:11 PM 9/1/2002 -0700, Michael Sisolak wrote:
>Andi,
>
>I download the alpha2 version of the php-4.3.0-dev-zend2 release.
>Unfortunatley out-of-the-box I got an "Invalid access to memory
>location." error returned when I try to view I page.  I was able to
>track it down to something with the browscap processing - something in
>ini_parse() is causing a memory access violation, but I get lost in all
>the lex code trying to figure out exactly what is going on.  I disabled
>my browscap entry and was able to continue with the testing.

That's strange. I know browsecap isn't really supposed to work (I commented 
out lots of code to get Engine 2 to work) but it shouldn't crash. It 
doesn't crash for me. Are you actually calling it? Can you try not loading it?


>It does appear that the issue I'm seeing with the first thread getting
>the GLOBAL_FUNCTION_TABLE as it's own local copy is fixed in Zend2:
>
>[1340] the startup thread is 1996
>[1340] copying the GLOBAL_FUNCTION_TABLE from 20933432
>[1340] in HttpExtensionProc thread 1996, CG(function table) is 21138360
>[1340] copying the GLOBAL_FUNCTION_TABLE from 20933432
>[1340] in HttpExtensionProc thread 532, CG(function table) is 22055840
>[1340] in HttpExtensionProc thread 1996, CG(function table) is 21138360
>
>The initial thread does now get it's own copy of the
>GLOBAL_FUNCTION_TABLE.  Since it will be a while before Zend2 is
>production quality do you think it would be possible to port what makes
>this work in Zend2 back to 4.2.x?  The changes in zend.c seem fairly
>straight forward, but there may be interactions with other changes I'm
>not seeing.

This code is quite complex as you have probably noticed. I moved some stuff 
around there for Engine 2 but it's not very easy to port these changes back 
to Engine 1 especially as I'm not sure I actually fixed any bugs. Bugs 
weren't the reason for me shifting it around. If you can figure out what 
changes in Engine 2 actually make the difference then we can look at them 
but it might mean lots of work for you.

Andi


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

Re: [PHP-DEV] Sound API for php

[Andi Gutmans]

You might want to put this into Pear. In any case, if you want to post the 
API just to get people's input (naming conventions of functions and so on) 
feel free to post here.

Andi

At 06:28 PM 9/7/2002 +0100, Tony Leake wrote:
>Hi,
>
>I have started to write an audio api for PHP.
>
>I have written a wrapper to ecasound which is a very powerful
>audio processing library that runs on Linux and I believe several
>other *NIX's. At the simple end it will play audio files in most
>audio formats (wav, mp3, ogg-vorbis, AIFF etc) and convert files
>between any supported formats.
>
>At the higher end, ecasound can be used to create a full multi-track
>recording/mixing system in just a few lines of code.
>
>Ecasound currently has bindings for c, c++, perl and python so I
>decided to address the balance to write PHP bindings. I currently
>have this working and am testing it. It will then be possible to
>write advanced audio applications in PHP with a Gtk interface.
>
>My next stage will be to write higher level functions for simple
>tasks such as playing an MP3 file, as, like most powerful libraries,
>the ecasound interface can be cryptic at times.
>
>Further on I plan to write midi functions once I find a suitable
>library.
>
>My question is, is there any interest in bundling an audio extension
>with PHP. If not then I will run this on sourceforge as a separate
>project, but if there is I will publish my proposed api to ensure that
>it is compatible with the rest
>of PHP.
>
>Regards
>Tony Leake
>
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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

Re: [PHP-DEV] Sound API for php

[Andi Gutmans]

At 11:00 AM 9/8/2002 +0100, Wez Furlong wrote:

> > 3) will be midi functions,this is a long way off yet so I haven't given
> > it too much thought yet. Also it is likely to be a separate module as it
> > will need to link against a separate library and I can't think of any
> > PHP modules that link against 2 libs.
>
>I don't think there is a need to make this into two separate extensions
>(it just makes things harder for the end user) - you can link to as many
>libs as you like from your extension.

This isn't quite true. Theoretically you (as the end-user) shouldn't load a 
GPL library with PHP (as that can be looked upon as linking). Only LGPL 
works in such a case.
However, often one can get permission from the author of the GPL library.

Andi


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

[PHP-DEV] Re: [Zend Engine 2] PHP/ZE2 win32 snapshots Bug with Constants

[Andi Gutmans]

This sounds very strange. It sounds to me as if your scanner wasn't built 
correctly for some odd reason.

Andi

At 10:45 AM 9/6/2002 +0200, phpsurf wrote:
>Hi
>
>I tried the latest windows binaries of PHP with ZE2 built yesterday by Edin
>on http://snaps.php.net/win32/ZE2 and there is still a bug with pre-defined
>boolean constants :
>
>when php is used as an apache module (apache 1.3.24)
>
>
>var_dump(True);
>var_dump(TrUe);
>var_dump(False);
>var_dump(FaLse);
>
>?>
>
>outputs:
>
>string(4) "True"
>string(4) "TrUe"
>string(5) "False"
>string(5) "FaLse"
>
>instead of:
>
>bool(true)
>bool(true)
>bool(false)
>bool(false)
>
>but what is strange is that when this script is called in command line:
>php -f test.php, then it outputs
>
>bool(true)
>bool(true)
>bool(false)
>bool(false)
>
>
>
> > -Original Message-
> > From: Edin Kadribasic [mailto:[EMAIL PROTECTED]]
> > Sent: jeudi 5 septembre 2002 14:07
> > To: [EMAIL PROTECTED]
> > Subject: [PHP-DEV] PHP/ZE2 win32 snapshots available
> >
> >
> > Hello all,
> >
> > Windows snapshots of the latest version of PHP featuring ZE2 are
> > available at:
> >
> > http://snaps.php.net/win32/ze2/
> > or
> > http://ftp.proventum.net/pub/php/win32-snapshots/ze2/
> >
> > Edin
> >
> >
> >
> >
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
>
>__
>Pour mieux recevoir vos emails, utilisez un PC plus performant !
>Découvrez la nouvelle gamme DELL en exclusivité sur i (france)
>http://www.ifrance.com/_reloc/signedell


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

Re: [PHP-DEV] Re: var_export() and arrays

[Andi Gutmans]

At 02:48 PM 9/4/2002 +0900, Yasuo Ohgaki wrote:
>Sebastian Bergmann wrote:
>> > $array = array('foo', 'bar');
>> var_export($array);
>> ?>
>>   prints
>> array (
>>   0 => 'foo',
>>   1 => 'bar',
>> )
>>   The comma after 'bar' is superfluous.
>
>I agree, but it has been discussed recently.
>Derick added extra , since it should not harm
>any.
>
>(there are shell script languages accept
>extra , like this also)

C also allows the extra , exactly for the reason of auto-generated source 
files.

Andi


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

Re: [PHP-DEV] [PATCH] [ZE] More useful error message for class redeclaration

[Andi Gutmans]

Can't you make sure that the filename of internal classes will be NULL and 
then we can check for it and say it's an internal class?

Andi

At 03:59 PM 9/23/2002 +0100, Wez Furlong wrote:
>X-Managedo-partname: name="1.1"; mimetype="text/plain"
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: 7bit
>
>I'm resubmitting this little patch for the ZE; when presented with
>code like this:
>
>class Foo {
>}
>
>class Foo {
>}
>?>
>
>The engine will generate an error message like this:
>
>Cannot redeclare class Foo (previously declared in file.php:2)
>
>Caveat Emptor: if someone tries to redeclare an internal/builtin class
>such as Directory, the previous declaration will appear to be the
>actual declaration in the script.  I'm not sure of the best way to
>resolve this.
>
>--Wez.
>
>--
>Wez Furlong
>The Brain Room Ltd.
>
>X-Managedo-partname: name="1.2"; mimetype="text/plain"
>Content-Type: text/plain
>Content-Transfer-Encoding: 7bit
>Content-Disposition: attachment;
>  filename="redclare_class.diff.txt"
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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

Re: [PHP-DEV] [PATCH] [ZE] More useful error message for class redeclaration

[Andi Gutmans]

If the zend_hash_add() fails then you can do a zend_hash_find() to retreive 
the class which is in the hash and print its information. If its 
information is NULL (we have to make sure we init it) then you can print 
out a message that it's an internal class. Does that make sense?

Andi

At 06:26 PM 9/23/2002 +0100, Wez Furlong wrote:
>The problem is (as I understand it!) that the ZEND_DECLARE_CLASS case in 
>do_bind_function_or_class retrieves the class entry for the user-defined
>class and not the internal class, and that is why the message reflects
>the user class.
>
>I can't really see why this is the case, but then I haven't really delved
>into how it all works :-/
>
>--Wez.
>
>
>On 09/23/02, "Andi Gutmans" <[EMAIL PROTECTED]> wrote:
> > Can't you make sure that the filename of internal classes will be NULL and
> > then we can check for it and say it's an internal class?
> >
> > Andi
> >
> > At 03:59 PM 9/23/2002 +0100, Wez Furlong wrote:
> > >Caveat Emptor: if someone tries to redeclare an internal/builtin class
> > >such as Directory, the previous declaration will appear to be the
> > >actual declaration in the script.  I'm not sure of the best way to
> > >resolve this.


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

Re: [PHP-DEV] sticky perms in CVS?

[Andi Gutmans]

At 07:22 PM 9/23/2002 +0100, Wez Furlong wrote:
>Am I the only one who is getting their files chmod'ed to read-only
>every time I do a CVS commit?
>In particular, main/user_streams.c keeps doing this which is quite
>annoying - is there some setting on the server side that affects this?
>(and do we want it switched on?)

No idea. It's never happened to me. Not that I think it can have anything 
to do with it but is your umask OK?

Andi


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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard config.m4 css.c css.h info.c /main php_ini.c /sapi/aolserver aolserver.c /sapi/apache php_apache.c

[Andi Gutmans]

At 11:01 AM 9/24/2002 -0400, Colin Viebrock wrote:
> > It obviously is not compatible with current browsers as it
> > is really ugly in IE and NS.
>
>It looks pretty much identical to the way it did before in MSIE 5+ and
>NS 6+ and Mozilla.  It only looks "ugly" (i.e. not as nice as before) in
>NS 4.x, a broswer that almost no one uses anymore.
>
> > Indeed, why did you have to change it? Just to get CSS in there?
>
>
>As I said, it was to reduce the size of the file considerably.

Just out of curiosity, what was the size before/after?

Andi


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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/session session.c

[Andi Gutmans]

Please use sizeof("sid") and not 4 in such code.
Also, why use hash_find() if just calling hash_del() would work?

Andi

At 12:05 AM 9/27/2002 +0200, Markus Fischer wrote:
> Guys,
>
> _Please_ include bug fixes in NEWS entries (or separately
> commit them) so we've complete log.
>
> Browsing back the ChangeLog and finding missing treasures
> ain't that funny.
>
> ;)
>
> thanks,
>
> - Markus
>
>On Thu, Sep 26, 2002 at 06:12:27PM -, Ilia Alshanetsky wrote :
> > iliaa Thu Sep 26 14:12:27 2002 EDT
> >
> >   Modified files:
> > /php4/ext/session session.c
> >   Log:
> >   Fixed bug #11643
> >
> >
> > Index: php4/ext/session/session.c
> > diff -u php4/ext/session/session.c:1.317 php4/ext/session/session.c:1.318
> > --- php4/ext/session/session.c:1.317  Thu Sep 26 12:46:21 2002
> > +++ php4/ext/session/session.cThu Sep 26 14:12:27 2002
> > @@ -17,7 +17,7 @@
> > 
> +--+
> >   */
> >
> > -/* $Id: session.c,v 1.317 2002/09/26 16:46:21 sniper Exp $ */
> > +/* $Id: session.c,v 1.318 2002/09/26 18:12:27 iliaa Exp $ */
> >
> >  #ifdef HAVE_CONFIG_H
> >  #include "config.h"
> > @@ -826,6 +826,7 @@
> >   int module_number = PS(module_number);
> >   int nrand;
> >   int lensess;
> > + zend_constant *c;
> >
> >   PS(apply_trans_sid) = PS(use_trans_sid);
> >
> > @@ -919,7 +920,11 @@
> >   php_session_send_cookie(TSRMLS_C);
> >   }
> >
> > -
> > + /* check if SID constant exists, if it does destroy it. */
> > + if (zend_hash_find(EG(zend_constants), "sid", 4, (void **) &c) != 
> FAILURE) {
> > + zend_hash_del(EG(zend_constants), "sid", 4);
> > + }
> > +
> >   if (define_sid) {
> >   smart_str var = {0};
> >
> >
> >
> >
> > --
> > PHP CVS Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
>
>--
>GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
> Derick, while ($xml) $ass->get_new_ideas();
><[James]> Markus: IE on_user_fart()
>-- People doesn't seem to like the new XHTML2 specs :) --
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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

Re: [PHP-DEV] Feature request -- feedback welcomed.

[Andi Gutmans]

You already have "public" which you can use instead of "var".
I think method would look very nice but I don't think it's worth creating 
another reserved word.

Andi

At 01:34 PM 9/28/2002 -0600, Lamont R. Peterson wrote:
>All:
>
>I can't hardly wait for PHP 4.3 (Zend 2.0) to hit the streets.  I can't
>express how anxiously I've been waiting for the class model to be reworked.
>Great job!
>
>I would, however, like to see a couple of simple additions to the planned
>release (if these are already coming, then I just haven't seen is talked
>about anywhere).  I would love to have "method" as an alias for "function"
>and "member" as an alias for "var".  These could be just plain aliases, but
>it would be nice if these aliases were only valid within a class definition.
>
>I would love to hear peoples thoughts on this one.  Where I work, the kind of
>software we write on PHP,  it only makes sense to use objects.  However, we
>do mix in plain functions liberally when there is no need for the features of
>an object.  I've worked this way with PHP ever since 4.0.0 was released.
>--
>Sincerely,
>Lamont R. Peterson <[EMAIL PROTECTED]>
>801-580-7323 [cell]
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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

Re: [PHP-DEV] Re: cvs: php4 /ext/pgsql pgsql.c php_pgsql.h

[Andi Gutmans]

It doesn't really make sense to me to add an alias to MySQL if it's not needed.
The less aliases we have in PHP the better IMO.

Andi

At 11:04 AM 10/3/2002 +0900, Yasuo Ohgaki wrote:
>Ok. I'll add alias to mysql and rename pgsql function.
>
>--
>Yasuo Ohgaki
>
>Derick Rethans wrote:
>>On Wed, 2 Oct 2002, Marcus Börger wrote:
>>
>>>At 13:41 02.10.2002, Dan Kalowsky wrote:
>>>
On Wednesday, October 2, 2002, at 12:10 AM, Yasuo Ohgaki wrote:

>I don't mind to have alias like pg_result_seek() or
>have only pg_result_seek().

I would rather see it named pg_result_seek as it is more consistent 
with what this function accomplishes.  It also opens the door for ODBC 
to follow in these steps a bit more.
>>>
>>>
>>>So why not add an alias for the mysql function and use the
>>>preferred name?
>>
>>Sounds good to me
>>Derick
>>--
>>---
>>  Derick 
>> Rethans   http://derickrethans.nl/  JDI 
>> Media Solutions
>>--[ if you hold a unix shell to your ear, do you hear the c? ]-
>>
>
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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

Re: [PHP-DEV] ini_set("register_globals", 1);

[Andi Gutmans]

I don't think this is a good idea because some code which runs before the 
script runs depends on this.
It doesn't make sense to make such a hack just for the tests, just to get 
some session code to run differently.

Andi

At 09:01 AM 10/3/2002 +0200, Sascha Schumann wrote:
> The session test scripts need to set register_globals -- does
> anyone see a problem with making that option setable in the
> script?
>
> - Sascha
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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

Re: [PHP-DEV] [PATCH] .phps support for Apache 2

[Andi Gutmans]

ctx->r->handler[strlen("application/x-httpd-php")]

Is this actually the way it's supposed to work? (based on the length)? 
Unless there's something I'm missing I'd prefer to see an strcmp() here. It 
might be a bit slower but it's definitely more robust for future changes.

Andi

At 12:06 PM 10/4/2002 -0400, Ilia A. wrote:
>The attached patch adds .phps file support for Apache 2, allowing Apache 2
>users to show prettified source of their scripts, just like their Apache 1
>counterparts can.
>
>It is a fairly simple patch, that adds just 2 cmp overhead for this
>functionality, so its not too bad imho.
>Please review the patch and let me know if there are any objections to it's
>addition.
>
>Ilia
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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

Re: [PHP-DEV] 4.3 plans

[Andi Gutmans]

Sounds good to me.

Andi

At 10:09 AM 10/7/2002 -0400, Andrei Zmievski wrote:
>I think the general consensus is that PHP tree is not ready for
>branching and RC1. So, here 's what I propose: we roll a 4.3.0-pre1 from
>HEAD on Thursday, so that QA team (or what's left of it) and everyone
>else can test it. Subsequently, based on the results of that testing we
>can see if branching for RC1 will make sense or if we should roll RC's
>from HEAD and branch later. Agreed?
>
>-Andrei   http://www.gravitonic.com/
>
>Work is of two kinds: first, altering the position of matter at or near
>the earth's surface relatively to other matter; second, telling other people
>to do so. The first kind is unpleasant and ill-paid, the second is pleasant
>and highly paid. -- Bertrand Russell
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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

Re: [PHP-DEV] 4.3 plans

[Andi Gutmans]

Wow. Zeev and I used the *exact* same sentence. Scary...

Andi

At 05:19 PM 10/7/2002 +0300, Zeev Suraski wrote:
>Sounds good to me.
>
>At 17:09 07/10/2002, Andrei Zmievski wrote:
>>I think the general consensus is that PHP tree is not ready for
>>branching and RC1. So, here 's what I propose: we roll a 4.3.0-pre1 from
>>HEAD on Thursday, so that QA team (or what's left of it) and everyone
>>else can test it. Subsequently, based on the results of that testing we
>>can see if branching for RC1 will make sense or if we should roll RC's
>>from HEAD and branch later. Agreed?
>>
>>-Andrei   http://www.gravitonic.com/
>>
>>Work is of two kinds: first, altering the position of matter at or near
>>the earth's surface relatively to other matter; second, telling other people
>>to do so. The first kind is unpleasant and ill-paid, the second is pleasant
>>and highly paid. -- Bertrand Russell
>>
>>--
>>PHP Development Mailing List 
>>To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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

Re: [PHP-DEV] CODING_STANDARDS addition re: emalloc

[Andi Gutmans]

It might be a good idea to mention that almost in all cases memory returned 
to the engine has to be emalloced.
You can also mention that malloc() also should be used if the memory has to 
survive in between requests.

Andi

At 10:14 PM 10/8/2002 -0400, Jon Parise wrote:
>Attached is a patch that adds a new item to CODING_STANDARDS that
>suggests using emalloc() and friends over the standard C library
>version.  It also offers an explanation, courtesy of Rasmus' reply to
>my earlier question on the subject.
>
>If no one objects to the addition in principle or in wording, I'll
>commit this in a few days.
>
>--
>Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/)
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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

Re: [PHP-DEV] CODING_STANDARDS addition re: emalloc

[Andi Gutmans]

Looks good!

Andi

At 09:47 AM 10/9/2002 -0400, Jon Parise wrote:
>A new CODING_STANDARDS patch is attached, based on feedback from Andi
>and Dan (thanks!).  Please review and comment.
>
>--
>Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/)


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

[PHP-DEV] Re: [PHP-CVS] cvs: php4 / php.ini-dist

[Andi Gutmans]

Hey,

If the fopen() fails why not create the directory? It shouldn't be too hard 
to do and it'd really improve usability.

Andi

At 09:03 AM 10/9/2002 +, Sascha Schumann wrote:
>sas Wed Oct  9 05:03:04 2002 EDT
>
>   Modified files:
> /php4   php.ini-dist
>   Log:
>   Emphasize a couple of points
>
>
>Index: php4/php.ini-dist
>diff -u php4/php.ini-dist:1.164 php4/php.ini-dist:1.165
>--- php4/php.ini-dist:1.164 Tue Oct  8 03:47:45 2002
>+++ php4/php.ini-dist   Wed Oct  9 05:03:04 2002
>@@ -766,15 +766,17 @@
>  ; Argument passed to save_handler.  In the case of files, this is the path
>  ; where data files are stored. Note: Windows users have to change this
>  ; variable in order to use PHP's session functions.
>-; As of PHP 4.2.3, you can define the path as:
>+; As of PHP 4.0.1, you can define the path as:
>  ; session.save_path = "N;/path"
>  ; where N is an integer.  Instead of storing all the session files in
>-; /path, what this will do is create subdirectories N-levels deep, and
>+; /path, what this will do is use subdirectories N-levels deep, and
>  ; store the session data in those directories.  This is useful if you
>  ; or your OS have problems with lots of files in one directory, and is
>  ; a more efficient layout for servers that handle lots of sessions.
>-; (Note: see the section on garbage collection below if you choose to
>-; use subdirectories for session storage)
>+; NOTE 1: PHP will not create this directory structure automatically.
>+; You can use the script in the ext/session dir for that purpose.
>+; NOTE 2: See the section on garbage collection below if you choose to
>+; use subdirectories for session storage
>  session.save_path = /tmp
>
>  ; Whether to use cookies.
>
>
>
>--
>PHP CVS Mailing List (http://www.php.net/)
>To unsubscribe, visit: http://www.php.net/unsub.php


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

Re: [PHP-DEV] Re: session_register warnings

[Andi Gutmans]

Unless we're missing some problem I agree with Rasmus here.
I don't see much advantage in changing this.
Of course, there might be a reason
Andi

At 10:40 AM 10/9/2002 -0700, Rasmus Lerdorf wrote:
>On Wed, 9 Oct 2002, Sascha Schumann wrote:
> > > I'd like to do a collective rethink of this.  The simple description of
> > > the session_register() function in the manual is:
> >
> > This description was correct initially (I wrote it), but has
> > not been updated as the session module was extended.  I've
> > noticed this documentation issue in the earlier thread, but
> > have not come around to fix it yet.
> >
> > If I may refer you to the session index page again, that one
> > clearly stated since the beginning that the behaviour
> > changes, depending on register_globals.
> >
> > Now, if your application(s) rely on this feature and you
> > don't want to change them, you can always disable the
> > warning.
>
>I am not talking about just mine.  I am talking about a sizeable subset of
>all PHP apps that use sessions.  My problem here is that I do not
>understand the reasoning for not continuing to allow session_register to
>work on global variables regardless of the register_globals setting.  I
>do not see the benefit of changing this.
>
> > > make the function behave exactly as described in the short description.
> >
> > I suggest we fix the documentation.
> >
> > >  2. changing this breaks BC
> >
> > I'm not aware of any BC issues.  If you have a test case,
> > I'll be happy to look at it.
>
>The fact that we spew a warning is a pre-cursor to breaking BC.  If the
>plan is not to break BC on this issue then there is absolutely no reason
>for adding this warning and it should be removed.
>
>-Rasmus
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard array.c

[Andi Gutmans]

At 10:47 PM 10/9/2002 +0200, Sterling Hughes wrote:
>On Wed, 2002-10-09 at 22:45, Derick Rethans wrote:
> > On 9 Oct 2002, Sterling Hughes wrote:
> >
> > > On Wed, 2002-10-09 at 22:21, Thies C. Arntzen wrote:
> > > > On Wed, Oct 09, 2002 at 06:29:45PM -, Sterling Hughes wrote:
> > > > > sterlingWed Oct  9 14:29:45 2002 EDT
> > > > >
> > > > >   Modified files:
> > > > > /php4/ext/standard  array.c
> > > > >   Log:
> > > > >   clean these functions up using zend_parse_parameters and nuke 
> the use of
> > > > >   HASH_OF() which is inappropriate in these cases...
> > > >
> > > > will prev still work on objects after your patch?
> > > >
> > >
> > > none of them do - none of them should either - why would you want to
> > > access an object like you would an _indexed_ array?
> >
> > It breaks BC, s... revert? (Not that I see any use either :)
> > If you're at it, please add some tests for the test framework too.
> >
>
>Well, it breaks it in a "not-really-breaking-bc-manner."  To my
>knowledge this was never documented to work.  I don't think anyone will
>miss this feature - if someone will, and is/has used it, please write in
>and let me know, the patch can be modified to work on objects.  But then
>again, it really wouldn't work well on objects anyhow (even before my
>patch), so i really don't see the point.

Why wouldn't it work well? HASH_OF() was always used when the intention was 
for it to work for both arrays and objects.
Also, I doubt the php-cvs nor the php-dev forums can let you know if this 
feature is being used. You'd have to ask all of the PHP users out there.

Andi


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

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard array.c

[Andi Gutmans]

At 11:03 PM 10/9/2002 +0200, Sterling Hughes wrote:
>On Wed, 2002-10-09 at 22:56, Derick Rethans wrote:
> > On Wed, 9 Oct 2002, Andi Gutmans wrote:
> >
> > > At 10:35 PM 10/9/2002 +0200, Sterling Hughes wrote:
> > > >On Wed, 2002-10-09 at 22:21, Thies C. Arntzen wrote:
> > > > > On Wed, Oct 09, 2002 at 06:29:45PM -, Sterling Hughes wrote:
> > > > > > sterlingWed Oct  9 14:29:45 2002 EDT
> > > > > >
> > > > > >   Modified files:
> > > > > > /php4/ext/standard  array.c
> > > > > >   Log:
> > > > > >   clean these functions up using zend_parse_parameters and nuke 
> the
> > > > use of
> > > > > >   HASH_OF() which is inappropriate in these cases...
> > > > >
> > > > > will prev still work on objects after your patch?
> > > > >
> > > >
> > > >none of them do - none of them should either - why would you want to
> > > >access an object like you would an _indexed_ array?
> > > >
> > > >-Sterling
> > >
> > >
> > > You might want to traverse all of the members of an object.
> > > I find it worrying that people break BC whenever they feel like it and
> > > without consulting php-dev@ first.
> > >
> > > I think we should make a rule that BC should not be broken unless 
> discussed
> > > on php-dev.
> >
> > I have to agree about that...
> >
>
>I take that back, you could use key(), I guess, but there are certainly
>better ways to do that.
>
>Its not exactly breaking bc if its undocumented and widely unused.
>Php-dev and Php-cvs are not all users, but it does give a good
>"experience base" of people who have programmed php regularly and
>in-depth.
>
>Look at the proto of the function, its been that way for awhile, its
>been made clear that reset(), next() and prev() are meant for arrays.
>My guess is that this is legacy code (from what i can tell most php3
>code was written using the HASH_OF macro), but it was not intended to be
>this way.
>
>I wasn't wantonly breaking bc, as you can see even the function
>prototypes show that it was meant to be used with an array, so i kept it
>consistent with the documentation and prototypes, and what I considered
>to be reasonable leeway, i'll gladly change it back if that's the
>general concensus here though (I would like to hear that at least one
>person has actually used this though.)

I haven't :)
Anyway, I understand your reasoning. I just felt that lately too many 
things have been breaking around us.
I'm cc'ing php-dev as that is a bigger forum. Have any of you guys used 
these functions on objects? Do you think people use them?
Personally I agree that they shouldn't work but I'm just worried about 
breaking BC.

Andi


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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard array.c

[Andi Gutmans]

 From the feedback I think it's best to revert this. Please do so.
Thanks,

Andi

At 11:05 PM 10/9/2002 +0200, Andi Gutmans wrote:
>At 11:03 PM 10/9/2002 +0200, Sterling Hughes wrote:
>>On Wed, 2002-10-09 at 22:56, Derick Rethans wrote:
>> > On Wed, 9 Oct 2002, Andi Gutmans wrote:
>> >
>> > > At 10:35 PM 10/9/2002 +0200, Sterling Hughes wrote:
>> > > >On Wed, 2002-10-09 at 22:21, Thies C. Arntzen wrote:
>> > > > > On Wed, Oct 09, 2002 at 06:29:45PM -, Sterling Hughes wrote:
>> > > > > > sterlingWed Oct  9 14:29:45 2002 EDT
>> > > > > >
>> > > > > >   Modified files:
>> > > > > > /php4/ext/standard  array.c
>> > > > > >   Log:
>> > > > > >   clean these functions up using zend_parse_parameters and 
>> nuke the
>> > > > use of
>> > > > > >   HASH_OF() which is inappropriate in these cases...
>> > > > >
>> > > > > will prev still work on objects after your patch?
>> > > > >
>> > > >
>> > > >none of them do - none of them should either - why would you want to
>> > > >access an object like you would an _indexed_ array?
>> > > >
>> > > >-Sterling
>> > >
>> > >
>> > > You might want to traverse all of the members of an object.
>> > > I find it worrying that people break BC whenever they feel like it and
>> > > without consulting php-dev@ first.
>> > >
>> > > I think we should make a rule that BC should not be broken unless 
>> discussed
>> > > on php-dev.
>> >
>> > I have to agree about that...
>> >
>>
>>I take that back, you could use key(), I guess, but there are certainly
>>better ways to do that.
>>
>>Its not exactly breaking bc if its undocumented and widely unused.
>>Php-dev and Php-cvs are not all users, but it does give a good
>>"experience base" of people who have programmed php regularly and
>>in-depth.
>>
>>Look at the proto of the function, its been that way for awhile, its
>>been made clear that reset(), next() and prev() are meant for arrays.
>>My guess is that this is legacy code (from what i can tell most php3
>>code was written using the HASH_OF macro), but it was not intended to be
>>this way.
>>
>>I wasn't wantonly breaking bc, as you can see even the function
>>prototypes show that it was meant to be used with an array, so i kept it
>>consistent with the documentation and prototypes, and what I considered
>>to be reasonable leeway, i'll gladly change it back if that's the
>>general concensus here though (I would like to hear that at least one
>>person has actually used this though.)
>
>I haven't :)
>Anyway, I understand your reasoning. I just felt that lately too many 
>things have been breaking around us.
>I'm cc'ing php-dev as that is a bigger forum. Have any of you guys used 
>these functions on objects? Do you think people use them?
>Personally I agree that they shouldn't work but I'm just worried about 
>breaking BC.
>
>Andi
>
>
>--
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php


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

[PHP-DEV] GD memory allocation

[Andi Gutmans]

Hi,

GD uses malloc()/free() and friends (gdhelpers.c). Unless there is stuff in 
gd which has to survive between requests, as we have its source in our tree 
it might be beneficial to move to emalloc() and friends.

Andi


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

Re: [PHP-DEV] Feature ./ correction to design flaw request

[Andi Gutmans]

If there's no concrete reason it is needed I think things should stay as 
they are.
One reason - it's slower, probably not noticeable but it still is.

Andi

At 03:06 PM 10/14/2002 +0100, Nick Lindridge wrote:
> >why would one want to have different executors/compilers in
> >different threads?
>
>I can't answer this question Thies, and one could achieve it as-is by
>having a thread safe delegator, but as far as possible I'd suggest that
>publicly exposed features of the engine should work across supported
>platforms, and isn't the case with these hooks.
>
>I remember the days when myself and other kids were writing machine
>code non-flicker software on Sinclair ZX80's, and that was thought of
>as 'impossible' (as the CRT hardware was driven by software and any
>operations caused flicker), but actually this was possible if you'd a
>Z80 handbook to hand and didn't mind counting instruction cyles on all
>the possible branch paths, and pulled some tricks.
>
>This is just in my view and experience, but people will always use
>features and do things that designers of said features could never have
>conceived. Equally people will solve problems in different ways to
>others, and one has to mindful of this and accordingly endeavour to
>design without artificial constraints. If one knows that modifiable
>globals should be made thread safe on a threaded server then unless
>there's a good reason to not do it, it should be done, and not omitted
>just because the developer 'didn't think that it would be useful'.
>Genuine omissions, as was probably the case here, are fine, and we all
>make them, but should then be scheduled for correction once discovered
>for the benefit of future developments, and to improve the quality of
>the product as a whole.
>
>
>
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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

Re: [PHP-DEV] Segfaults in Zend

[Andi Gutmans]

Also here, best to have a short 10-20 line reproducing script.

Andi

At 12:19 PM 10/14/2002 +0200, Jan Schneider wrote:
>Zitat von Yasuo Ohgaki <[EMAIL PROTECTED]>:
>
> > > 0x4055778f in _efree (ptr=0x83476e4)
> > > at /home/jan/software/php4/Zend/zend_alloc.c:229
> > > 229 REMOVE_POINTER_FROM_LIST(p);
> > > (gdb) bt
> > > #0  0x4055778f in _efree (ptr=0x83476e4)
> > > at /home/jan/software/php4/Zend/zend_alloc.c:229
> > > #1  0x405664a1 in _zval_dtor (zvalue=0x83456bc)
> > > at /home/jan/software/php4/Zend/zend_variables.c:44
> > > #2  0x4055e4c1 in _zval_ptr_dtor (zval_ptr=0x40605714)
> > > at /home/jan/software/php4/Zend/zend_execute_API.c:293
> > > #3  0x4057516d in execute (op_array=0x835c0c4)
> >
> > If you could tell us what execute() is trying to execute,
> > it would be useful.
>
>(gdb) frame 3
>#3  0x4057516d in execute (op_array=0x8353ebc)
> at /home/jan/software/php4/Zend/zend_execute_locks.h:26
>26  zval_ptr_dtor(&EG(garbage)[--EG(garbage_ptr)]);
>(gdb) print (char
>*)(executor_globals.function_state_ptr->function)->common.function_name
>$1 = 0x82f313c "flist"
>
>flist() is the function mentioned earlier, that segfaults while returning to
>the calling function.
>
> > Did you read my email? (and the URL?)
> > http://bugs.php.net/bugs-generating-backtrace.php
>
>Sorry, I didn't know that it has been updated with instructions on how to
>locate the segfaulting function.
>
>Jan.
>
>--
>http://www.horde.org - The Horde Project
>http://www.ammma.de - discover your knowledge
>http://www.tip4all.de - Deine private Tippgemeinschaft
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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

Re: [PHP-DEV] Re: Segfaults in 4.2.3?

[Andi Gutmans]

What we'd really need is a short 10-20 line reproducing script.

Andi

At 11:20 AM 10/14/2002 -0700, Aaron Gowatch wrote:
>Heres a backtrace from one of my SIGSEGVs.  This one looks a little
>different from previous segfaults, but perhaps it can help track this bug
>down:
>
>Program received signal SIGSEGV, Segmentation fault.
>0x42082a0c in memcpy () from /lib/i686/libc.so.6
>(gdb) bt
>#0  0x42082a0c in memcpy () from /lib/i686/libc.so.6
>#1  0x0813865a in _mem_block_check (ptr=0x8bb30d4, silent=0,
>__zend_filename=0x8248882 "zend_stack.c",
> __zend_lineno=103, __zend_orig_filename=0x0, __zend_orig_lineno=0) at
>zend_alloc.c:650
>#2  0x0813861d in _mem_block_check (ptr=0x8bb30d4, silent=1,
>__zend_filename=0x8248882 "zend_stack.c",
> __zend_lineno=103, __zend_orig_filename=0x0, __zend_orig_lineno=0) at
>zend_alloc.c:642
>#3  0x08137877 in _efree (ptr=0x8bb30d4, __zend_filename=0x8248882
>"zend_stack.c", __zend_lineno=103,
> __zend_orig_filename=0x0, __zend_orig_lineno=0) at zend_alloc.c:224
>#4  0x08146e3a in zend_stack_destroy (stack=0x8298870) at zend_stack.c:103
>#5  0x08138c0f in shutdown_compiler () at zend_compile.c:100
>#6  0x08148257 in zend_deactivate () at zend.c:601
>#7  0x080a5068 in php_request_shutdown (dummy=0x0) at main.c:789
>#8  0x08153fca in apache_php_module_main (r=0x82d4ddc, 
>display_source_mode=0) at sapi_apache.c:96
>#9  0x080a2690 in send_php (r=0x82d4ddc, display_source_mode=0, 
>filename=0x0) at mod_php4.c:575
>#10 0x080a26de in send_parsed_php (r=0x82d4ddc) at mod_php4.c:590
>#11 0x08174547 in ap_invoke_handler (r=0x82d4ddc) at http_config.c:538
>#12 0x081837ef in process_request_internal (r=0x82d4ddc) at 
>http_request.c:1308
>#13 0x08183852 in ap_process_request (r=0x82d4ddc) at http_request.c:1324
>#14 0x0817d0bc in child_main (child_num_arg=0) at http_main.c:4629
>#15 0x0817d2b3 in make_child (s=0x829b704, slot=0, now=1034578800) at 
>http_main.c:4799
>#16 0x0817d330 in startup_children (number_to_start=5) at http_main.c:4826
>#17 0x0817d82c in standalone_main (argc=3, argv=0xbb14) at 
>http_main.c:5134
>#18 0x0817df50 in main (argc=3, argv=0xbb14) at http_main.c:5482
>#19 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6
>
>I'll leave my gdb attached in case more information is needed.
>
>Thanks in advance,
>Aa.
>
>(Apologies if this is received twice)
>
>On Sun, 13 Oct 2002, Aaron Gowatch wrote:
>
> > My apache children have been segfaulting for a few weeks now.  My attempts
> > to debug them leads me to believe that its happening in php somewhere.
> > The SIGSEGV actually occurs in chunk_alloc, after a malloc and several
> > calls to execute.  (I'll fwd a backtrace per the bugs docs as soon as my
> > gdb -p catches the SIGSEGV).
> >
> > This weekend, I started apache with MALLOC_CHECK_=2 and built my php with
> > --enable-debug.  Some interesting things started appearing in the logs:
> >
> > [Sat Oct 12 19:58:16 2002]  Script:
> > '/var/www/vhost/webmail.divinia.com/docs/src/login.php'
> > ---
> > zend_stack.c(103) : Block 0x08C6E628 status:
> > Beginning:   Overrun (magic=0x08415420, expected=0x7312F8DC)
> > [Sat Oct 12 19:58:17 2002] [notice] child pid 3037 exit signal 
> Segmentation fault (11)
> >
> > [Sat Oct 12 18:50:42 2002]  Script:
> > '/var/www/vhost/www.divinia.com/docs/mail/src/read_body.php'
> > ---
> > zend_stack.c(103) : Block 0x08BAF388 status:
> > Beginning:   Overrun (magic=0x08415420, expected=0x7312F8DC)
> > [Sat Oct 12 18:50:42 2002] [notice] child pid 4672 exit signal 
> Segmentation fault (11)
> >
> > Then some pretty whack stuff (that looks like trampled memory) starts
> > showing up:
> >
> > Sun Oct 13 15:08:02 2002] [notice] child pid 28803 exit signal Aborted (6)
> > Unknown(0) : Warning - String is not zero-terminated (base_uri) (source:
> > zend_execute_API.c:274)
> > Unknown(0) : Warning - String is not zero-terminated (Z
> >Ì*)
> > (source: zend_opcode.c:159)
> > [Sun Oct 13 15:08:14 2002]  Script:
> > '/var/www/vhost/webmail.divinia.com/docs/src/login.php'
> > ---
> > zend_opcode.c(159) : Block 0x08698778 status:
> > zend_variables.c(44) : Actual location (location was relayed)
> > Beginning:   Cached (allocated on zend_language_scanner.c:4150, 9 bytes)
> >   End:  OK
> > ---
> >
> > 
> 
>ÀàBÀàBpÀ=XïXïØàBØàBààBààBph£ðàBðàBøàBøàB(÷(ááBáBáBÝݸ¾¸¾(áB(áB0áB0áB8áB8áB@áB@áBHáBHáBPáBPáBÀÀ`áB`áBà#ror]
> 
>
> > [client 66.25.48.206] File does not exist:
> > /var/www/vhost/www.divinia.com/docs/
> > Unknown(0) : Fatal error - Maximum execution time of 30 seconds exceeded
> > 
> 
>ÀàBÀàBpÀ=XïXïØàBØàBààBààBpPsðàBðàBøàBøàB(÷(ááBáBáBÝݸ¾¸¾(áB(áB0áB0áB8áB8áB@áB@áBHáBHáBPáBPáBÀÀ`áB`áBà#02]
> 
>
> > [error] [client 66.25.48.206] File does not exist:
> > /var/www/vhost/www.divinia.com/docs/
> > images/max.gif
>

Re: [PHP-DEV] Feature ./ correction to design flaw request

[Andi Gutmans]

At 09:49 PM 10/14/2002 +0100, Nick Lindridge wrote:
> > One reason would be to allow for a product like APD to do JIT swapping
> > of executors to enable tracing on demand.  I imagine you could come up
> > with a clever way of letting Zend (En|De)coder be used for oly
> > prticular  clients in a large vhosting operation as well (although I
> > don't really  know how that product works.)
>
>Bingo! Well done George :) Nice to see someone thinking beyond their
>bubble.

Thanks for the compliment.

Andi


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

Re: [PHP-DEV] OCI extension help offer

[Andi Gutmans]

Hey,

I'm sure that if there's work to be done people using Oracle will 
appreciate your contribution.
Personally, I don't use Oracle so I suggest you talk to Thies who's the 
maintainer of the extension about the things you feel are missing. (It can 
also be public here on php-dev if you need feedback from other users).

Andi

At 01:51 PM 10/15/2002 +0200, Maxim Maletsky wrote:

>Guys, a few month ago, I have been trying to offer some of my help for
>developing Oracle 9i extension, or in anyway, to improve the existing
>PHP/Oracle functionality.
>
>original posts are here: 
>http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=aiquvp%2412e7%241%40FreeBSD.csie.NCTU.edu.tw&rnum=120&prev=/groups%3Fq%3DOCI8%2Bgroup:mailing.www.php-dev%26hl%3Den%26lr%3D%26ie%3DUTF-8%26scoring%3Dd%26start%3D110%26sa%3DN)
>
>
>Having put onto the real-life test OCI8 extensions for the Italian
>Government framework, I noticed many serious imperfections with the
>current OCI8 extension.
>
>I personally think that Oracle is very important for PHP's future, and
>that current extension is not very perfect and up to date.
>
>Please let me know if you are interested in my contributions regarding
>it.
>
>--
>Maxim Maletsky
>[EMAIL PROTECTED]
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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

Re: [PHP-DEV] short_open_tag

[Andi Gutmans]

I'll keep my message short:
NO!

I think removing short tags from PHP and/or as INI default is horrible.
Andi


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

[PHP-DEV] Fwd: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_execute.cphpdoc/scripts revcheck.php

[Andi Gutmans]

Any idea how that revcheck.php diff got into my Engine 2 patch? I commited 
from within the Zend/ directory.
Should something be reverted there?

Andi

Delivered-To: [EMAIL PROTECTED]
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
list-help: <mailto:zend-engine-cvs-help@;lists.php.net>
list-unsubscribe: <mailto:zend-engine-cvs-unsubscribe@;lists.php.net>
list-post: <mailto:zend-engine-cvs@;lists.php.net>
Delivered-To: mailing list [EMAIL PROTECTED]
From: "Andi Gutmans" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Date: Wed, 23 Oct 2002 20:26:27 -
X-Spam-Status: No, tests=bogofilter, spamicity=0.0% likelihood
Subject: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / 
zend_execute.c  phpdoc/scripts revcheck.php

andiWed Oct 23 16:26:27 2002 EDT

  Modified files:
/phpdoc/scripts revcheck.php
/ZendEngine2zend_execute.c
  Log:
  - Make Ts access a macro. I need this for my next patch which should
  - improve performance but not sure yet if it will.


--
Zend Engine CVS Mailing List (http://cvs.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Index: phpdoc/scripts/revcheck.php
diff -u phpdoc/scripts/revcheck.php:1.30 phpdoc/scripts/revcheck.php:1.31
--- phpdoc/scripts/revcheck.php:1.30Mon Oct  7 16:40:28 2002
+++ phpdoc/scripts/revcheck.php Wed Oct 23 16:26:27 2002
@@ -50,7 +50,7 @@
 
 // A file is criticaly "outdated' if
 define("ALERT_REV",   10); // translation is 10 or more revisions behind the en one
-define("ALERT_SIZE",  10); // translation is 10 or more kB smaller than the en one
+define("ALERT_SIZE",   3); // translation is  3 or more kB smaller than the en one
 define("ALERT_DATE", -30); // translation is 30 or more days older than the en one
 
 // Revision marks used to flag files
@@ -231,10 +231,10 @@
 }
 
 // Get the parameter if we have it
-list($trans_file) = func_get_args();
+list($trans_file, $en_size, $trans_size, $size_diff) = func_get_args();
 
-// Push file name with missing tag on the list
-$missing_tags[] = substr($trans_file, strlen($DOCDIR));
+// Push data of file with missing tag onto the list
+$missing_tags[] = array(substr($trans_file, strlen($DOCDIR)), $en_size, 
+$trans_size, $size_diff);
 }
 
 // Collect files by status mark
@@ -323,14 +323,6 @@
 $trans_tag = get_tag($trans_file, "\\S*");
 }
 
-// If we found no revision tag, then collect this
-// file in the missing tags list
-if (count($trans_tag) == 0) {
-files_by_mark(REV_NOTAG, 1);
-missing_tag($trans_file, $DOCDIR);
-return FALSE;
-}
-
 // Distribute values in separate vars for further processing
 list(, $this_rev, $this_maint, $this_status) = $trans_tag;
 
@@ -361,6 +353,14 @@
 $trans_date = intval((time() - filemtime($trans_file)) / 86400);
 $date_diff  = $en_date - $trans_date;
 
+// If we found no revision tag, then collect this
+// file in the missing tags list
+if (count($trans_tag) == 0) {
+files_by_mark(REV_NOTAG, 1);
+missing_tag($trans_file, $en_size, $trans_size, $size_diff);
+return FALSE;
+}
+
 // Make decision on file category by revision, date and size
 if ($rev_diff === 0) {
 $status_mark = REV_UPTODATE;
@@ -375,9 +375,6 @@
 // Store files by status, and by maintainer too
 files_by_mark ($status_mark, 1);
 files_by_maint($status_mark, $this_maint);
-
-if ($rev_diff === 0 && $this_maint == "")
-echo $file."\n";
 
 return array(
 "full_name"  => $file,
@@ -999,24 +996,27 @@
 if ($count > 0) {
 print "" .
   "\n".
-  "Files without Revision-comment ($count 
files):\n";
+  "Files without Revision-comment ($count 
+files):".
+  "Sizes in kB\n".
+  "en$LANGdiff\n";
 foreach($missing_tags as $val) {
 // Shorten the filename (we have directory headers)
-$short_file = basename($val);
+$short_file = basename($val[0]);
 
 // Guess the new directory from the full name of the file
-$new_dir = substr($val, 0, strrpos($val, "/"));
+$new_dir = substr($val[0], 0, strrpos($val[0], "/"));
 
 // If this is a new directory, put out dir headline
 if ($new_dir != $prev_dir) {
 
 // Print out directory header
-print "".dirname($val)."\n";
+print "".dirname($val[0])."\n";
 
 // Store the new actual directory
 $prev_dir = $new_dir;
 }
-print "$short_file\n";
+print "$short_file$val[1]".
+  "$val[2]$val[3]\n";
 }
 print "\n \n$navbar \n";
 
@@ -1060,7 +1060,7 @@
 }
 
  

Re: [PHP-DEV] short_open_tag

[Andi Gutmans]

I have to admit that after grep'ing a few hundred xml documents it does 
seem to make some sense to support this.
It's ugly but it works. The only question is what will we think of this in 
two years time? :)
By the way, I really think we should quit the 

Andi

At 06:12 PM 10/17/2002 +0200, Zeev Suraski wrote:
Well, I differ with you on that.  I don't think there's anything in the 
same class as 

Zeev

At 18:08 17/10/2002, Andi Gutmans wrote:
I don't think we should add special hacks to the scanner. Soon we're 
going to have a zillion hacks for other XML/SGML/foobar documents.

Andi

At 12:17 PM 10/16/2002 -0400, Ilia A. wrote:
Since the general consensus by the developers is not to remove the 
short_tags
or even disable them. Perhaps we should consider alternate solutions to this
problem. Given the buzzword popularity of XML and its slowly growing
popularity among website designers (XHTML) this issue is likely to come 
up in
the future yet again.
The solution I would like to offer, is a patch that adds special 
handling for

inside 

Ilia


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

Re: [PHP-DEV] short_open_tag

[Andi Gutmans]

At 01:09 AM 10/18/2002 +0200, Zeev Suraski wrote:

At 18:49 17/10/2002, Rasmus Lerdorf wrote:

 has whitespace.


And I personally think it's a bit pushing it.  How likely is it for 
someone to have a function called xml(), and then call it without a space 
from the 

I don't see why it's such a big deal for people who are creating xml to 
turn-off short tags?

Andi


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

Re: [PHP-DEV] short_open_tag

[Andi Gutmans]

This is definitely one thing to think about. This is exactly the reason why 
I was against in the beginning. I had a feeling such ambiguities could arise.

Andi

At 09:43 AM 10/17/2002 -0700, Rasmus Lerdorf wrote:
My main worry with such a hack would be breaking a script like this:

  
function xml() {
echo "Hello World";
}
  ?>
  ...
  
  ...

Now, people generally don't put spaces between the function name and the
(), but it is a BC concern since the above script works just fine today.

One idea would be to only strip 
tag.  That should cover most cases, but it may be a bit too magical.

-Rasmus

On Thu, 17 Oct 2002, Andrei Zmievski wrote:

> They are _not_ the same person!
>
> On Thu, 17 Oct 2002, Zeev Suraski wrote:
> > Well, I differ with you on that.  I don't think there's anything in the
> > same class as 
> >
> > Zeev
> >
> > At 18:08 17/10/2002, Andi Gutmans wrote:
> > >I don't think we should add special hacks to the scanner. Soon we're 
going
> > >to have a zillion hacks for other XML/SGML/foobar documents.
> > >
> > >Andi
> > >
> > >At 12:17 PM 10/16/2002 -0400, Ilia A. wrote:
> > >>Since the general consensus by the developers is not to remove the
> > >>short_tags
> > >>or even disable them. Perhaps we should consider alternate solutions to
> > >>this
> > >>problem. Given the buzzword popularity of XML and its slowly growing
> > >>popularity among website designers (XHTML) this issue is likely to come
> > >>up in
> > >>the future yet again.
> > >>The solution I would like to offer, is a patch that adds special 
handling
> > >>for
> > >>
> > >>inside 
> > >>
> > >>Ilia
> >
> >
> > --
> > PHP Development Mailing List <http://www.php.net/>
> > To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
> -Andrei   http://www.gravitonic.com/
>
> "Claiming Java is easier than C++ is like
>  saying that K2 is shorter than Everest."
>  -- Larry O'Brien (editor, Software Development)
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
>


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

Re: [PHP-DEV] short_open_tag

[Andi Gutmans]

At 10:14 AM 10/18/2002 +0200, Zeev Suraski wrote:

At 07:40 18/10/2002, Andi Gutmans wrote:

At 01:09 AM 10/18/2002 +0200, Zeev Suraski wrote:

At 18:49 17/10/2002, Rasmus Lerdorf wrote:

 has whitespace.


And I personally think it's a bit pushing it.  How likely is it for 
someone to have a function called xml(), and then call it without a 
space from the 

I don't see why it's such a big deal for people who are creating xml to 
turn-off short tags?

I don't see why it's such a big deal to have this thread quiet down for at 
least a couple of years, and making the lives of those who generate XML a 
bit easier, and their scripts more portable.

Why for a couple of years? Oh because we might end up finding out it wasn't 
such a good idea after all? :) It might lead to people wanting other new 
XML2/3/foobar tags to also be excluded?
Well anyway, as far as I'm concerned, it's not such a big deal either way 
and it's always fun to be able to say "I told you so" so I'll retire from 
this discussion. Admittedly there are good points to both sides.

Andi

P.S. - If we do go with it then the original patch of Ilia is probably a 
better idea for now.


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

Re: [PHP-DEV] Re: $_GET, $_POST, $_COOKIE, $_FILES == $_REQUEST?

[Andi Gutmans]

At 05:45 AM 10/16/2002 +0300, Jani Taskinen wrote:

On Wed, 16 Oct 2002, Yasuo Ohgaki wrote:

>Another option.
>
>How about remove $_FILES contents from $_REQUEST?
>It seems it has less impact.

+1 for this option. There's really no need it for to
be in $_REQUEST..


+1 from me too. I think it's fine not to have $_FILES in $_REQUEST. The 
main purpose of $_REQUEST was to have get/post/cookie in the same structure 
and always work with that. $_FILES is anyway a special case because its 
format is different.

Andi


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

Re: [PHP-DEV] short_open_tag

[Andi Gutmans]

I don't think we should add special hacks to the scanner. Soon we're going 
to have a zillion hacks for other XML/SGML/foobar documents.

Andi

At 12:17 PM 10/16/2002 -0400, Ilia A. wrote:
Since the general consensus by the developers is not to remove the short_tags
or even disable them. Perhaps we should consider alternate solutions to this
problem. Given the buzzword popularity of XML and its slowly growing
popularity among website designers (XHTML) this issue is likely to come up in
the future yet again.
The solution I would like to offer, is a patch that adds special handling for



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

Re: [PHP-DEV] Problems compiling HEAD

[Andi Gutmans]

I fixed the compile warning. Next time please mention it's in engine 2.

Thanks,

Andi

At 10:45 PM 10/19/2002 +0200, Marcus Boerger wrote:

I can no longer compile CVS version. See log:

[...]
Thank you for using PHP.

gcc  -Iext/zlib/ -I/usr/src/php4-HEAD/ext/zlib/ -DPHP_ATOM_INC 
-I/usr/src  [...]   -DZTS  -c /usr/src/php4-HEAD/ext/zlib/zlib.c -o 
ext/zlib/zlib.o  && echo > ext/zlib/zlib.lo
In file included from /usr/src/php4-HEAD/Zend/zend_globals.h:53,
 from /usr/src/php4-HEAD/Zend/zend_list.h:25,
 from /usr/src/php4-HEAD/Zend/zend_API.h:26,
 from /usr/src/php4-HEAD/main/php.h:38,
 from /usr/src/php4-HEAD/ext/zlib/zlib.c:28:
/usr/src/php4-HEAD/Zend/zend_compile.h:206: redefinition of 
`zend_execute_data'
/usr/src/php4-HEAD/Zend/zend_compile.h:62: `zend_execute_data' previously 
declared here
make: *** [ext/zlib/zlib.lo] Error 1

System is mandrake 8.2. And same configuration worked fine some days ago...

I also wonder why do we have to specify both --with-zlib and 
--with-zlib-dir now?
Wouldn't it be enoght to specify --with-zlib if wanted. I mean in that 
case we do
not need a second configure option to specify the same. O.k. if zlib extension
is not wanted that makes sense but the first case can be simplyfied.

Another thing is that we have different messages for -the -with-zlib-dir 
option:

[marcus@zaphod php4-HEAD]$ ./configure --help | grep zlib
  --with-zlib[=DIR]   Include ZLIB support (requires zlib >= 1.0.9).
  --with-zlib-dir=   Define the location of zlib install directory
  --with-zlib-dir[=DIR] GD: Set the path to libz install prefix.
  --with-zlib-dir[=DIR] PDFLIB: define libz install directory.

regards
marcus


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

Re: [PHP-DEV] Idea to extend language: Explicitly setting variablescope inside user defined function (longer)

[Andi Gutmans]

At 04:31 AM 10/21/2002 +0200, NTPT wrote:

Hi.
I have some idea and suggestion  how to extend PHP language a bit in some
way. That may probably lead to increasing of php flexibility, allow more
modular coding to be done etc


My sugestion is simple:
Allow  PHP programmer to explicitelly  told , WHAT variable scope will be
used  inside user defined  functions.

In the traditional approach (afaik , i use php 4.2.2 ), as is described in
the manual of php there a diferent varable scopes for each functions , only
syntax " global $valuename" ; can lead to use variables global. This aproach
is traditional and well known and is sufficient for most tasks.(I say
sufficient, not effective...). My idea is going a bit behind it.

I suggest  to introduce new keyword(s) or function(s)  into the PHP language
definiton
(i suggest syntax like  "var_scope scope" or  var_scope("scope") )

That keywords SHOULD be used in user defined  functions to  EXPLICITLY
define, WHAT kind of variable scope will be used inside this function.

scope can be either

'local' = it means, that all variables used in this function  have a local
scope only.(it means like traditional behavior of php and its variable
scopes until now )

'global' = each variable used in the function  is from global scope. Similar
to "global $variable_1,$variable_2... $each variable used in the
main execution line of the script"

'caller' or 'inherit' This is MOST USEFUL part of the idea . Function
variable scope is the SAME as from where the function was called. (if
functino bar(),with have var_scope set to 'caller', is called from function
foo() it have the same variable scope as function foo(), almost like the
code of function bar() was included (by include "something" ) somewhere
inside foo() )


I think having something like "caller" is very bad. It would mean that 
functions don't have any contracts anymore as they
can start messing around with the callers symbol table.

Andi


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

Re: [PHP-DEV] Work is beginning on cURL and PHP again

[Andi Gutmans]

At 01:54 AM 10/22/2002 +0200, Sterling Hughes wrote:

On Tue, 2002-10-22 at 01:38, Alan Knowles wrote:
> Non blocking connections would be nice...
>
> - On the generating stuff - why do you want to generate the code on the
> users system? -
> all the re2c stuff in CVS is 'pre-genereated'
>
> It would be nice to have extension generator that could be built upon,
> that didnt involve re-reading all those perl/awk manuals, just to add
> features to it. :)
> Any idea if  finding 'generic' bits in the php-gtk generator is possible?
>
Well, the reason for the generator, is it will build an extension that
mimics the current version of cURL installed which will allow the cURL
extension to support multiple versions of the library without a lot of
maintanence and stuff :)


Don't forget Windows. No idea how you'll handle that.

Andi


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

Re: [PHP-DEV] short_open_tag

[Andi Gutmans]

I don't get this. Are people replying to you directly and you're cc'ing to 
the list? Because I only see your answers and not their replies.

Andi

At 03:30 PM 10/22/2002 +1000, Terence Kearns wrote:


Yasuo Ohgaki wrote:



I see side effect of 

I think there is some sort of assumption by others that HTML is the only 
thing we need to worry about. I suspect the importance of XML compliance 
would be weighed up differently if people believed that PHP will be widely 
used for XML application in the future - particularly with version 5.

Before we have a discussion about short tage removal - "good or bad". We 
need to provide some context for the discussion.
For me, the context is "near future" and version 5.


--
Yasuo Ohgaki




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



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