[PHP-DEV] odbc_primarykeys return type

I am having difficulty obtaining a reply to the following questions: resource *odbc_primarykeys* ( resource connection_id, string qualifier, string owner, string table) resource *odbc_foreignkeys* ( resource connection_id, string pk_qualifier, string pk_owner, string pk_table, string fk_qualif

Re: [PHP-DEV] 4.2.3

I did not intend to reply to that, but generally, the reasons I think 4.2.3 should either be released in the immediate future or not released at all are (a) clashing with the 4.3.0 release process (b) momentum. The most serious problem PHP releases have suffered from, in my opinion, ever sense

Re: [PHP-DEV] References - good or bad

Hi, I've read "PHP 4: Reference Counting and Aliasing" By Andi Gutmans on Zend.com site (http://www.zend.com/zend/art/ref-count.php). Also I read this mail http://marc.theaimsgroup.com/?l=php-dev&m=100955714924477 from him. I would like to know more about how reference is managed by PHP4. I'm

[PHP-DEV] RE: [PHP-QA] RE: [PHP-DEV] 4.2.3

At 18:19 17-8-2002, Liz wrote: > > there should be 'fixed in the next bug-fix release' or 'fixed > > in the next > > semi-major release'. > >How about > >Will be fixed in version major.minor.buildrelease ?? ie tell them which >version it will be fixed in, no confusion at all then Actually - It's

[PHP-DEV] Re: 4.2.3

I agree with you, because 4.2.3dev is including some bugfix for mbstring, and it will take a couple of weeks until release of php-4.3. On Sat, 17 Aug 2002 13:47:19 +0300 [EMAIL PROTECTED] (Zeev Suraski) wrote: > I'd like to raise the option of releasing 4.2.3 again. I believe that it > woul

Re: [PHP-DEV] Re: [PHP-DOC] Re: #3793 [Ana->Opn]: session.gc_maxlifetime

Rasmus Lerdorf wrote: > Well, I wouldn't call that easy. To do it in the session handler you > would need to add a bunch of code to the write handler. It would need to > read the current session data, then compare that to the session data it > was called with, and if different write the new sess

Re: [PHP-DEV] trans-sid warning?

Il 02:48, domenica 18 agosto 2002, Rasmus Lerdorf ha scritto: > But the real issue here is about session hijacking. Yes, of course people > can send whatever session id they want to PHP. Since the session id comes > from the user we need to accept what is sent. This is what I consider uncon

Re: [PHP-DEV] Re: [PHP-DOC] Re: #3793 [Ana->Opn]: session.gc_maxlifetime

Well, I wouldn't call that easy. To do it in the session handler you would need to add a bunch of code to the write handler. It would need to read the current session data, then compare that to the session data it was called with, and if different write the new session data. You aren't saving m

Re: [PHP-DEV] Re: [PHP-DOC] Re: #3793 [Ana->Opn]: session.gc_maxlifetime

James E. Flemer wrote: > Would it be difficult to just add a "dirty" flag somewhere, It's easy. Write your own session save handler does this if needed. -- Yasuo Ohgaki -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] trans-sid warning?

But the real issue here is about session hijacking. Yes, of course people can send whatever session id they want to PHP. Since the session id comes from the user we need to accept what is sent. Perhaps a check should be added to make sure it looks like a proper session id before using it, but t

Re: [PHP-DEV] trans-sid warning?

Rasmus Lerdorf wrote: > > > Any propagation, doesn't matter. > > The passed id must exist, otherwise discarded and regenerated. > > I saw that php already creates the session at the start. > > > > The possibility to count on a stable name, because recreable anytime > > and though surviving gc, is

[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] 4.2.3

On Sat, 17 Aug 2002, Sascha Schumann wrote: > > I think 4.2.3 makes perfect sense as long as it gets started immediately, > > immediately being sometime within the next few days. > > Is there some event I'm not aware of that a few days matter > to you? If not, I don't see any problem wi

Re: [PHP-DEV] Major Problem

sorry about posting it then - i didnt realise "Sterling Hughes" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > On Sat Aug 17, 2002 at 11:4352PM +0100, Luke Rhodes wrote: > > > i thought of using a goto statement that goes back to a certain part of the > > >

Re: [PHP-DEV] Major Problem

> On Sat Aug 17, 2002 at 11:4352PM +0100, Luke Rhodes wrote: > > i thought of using a goto statement that goes back to a certain part of the > > page but i cant find any goto info anywhere. > > There is no goto function/construct in PHP and there will be surely > none in the future. > Besides, h

Re: [PHP-DEV] Major Problem

On Sat Aug 17, 2002 at 11:4352PM +0100, Luke Rhodes wrote: > i thought of using a goto statement that goes back to a certain part of the > page but i cant find any goto info anywhere. There is no goto function/construct in PHP and there will be surely none in the future. -- - Martin

[PHP-DEV] Major Problem

i am creating a mysql chat script and i have got all the mysql functions under control. i have the script that will chack if another user has posted (by checking the database) then refreshing if it has, but i find this doesnt work to well and so i want to just update the text field on the form, n

RE: [PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] 4.2.3

> -Original Message- > From: Sascha Schumann [mailto:[EMAIL PROTECTED]] > Sent: Saturday, August 17, 2002 11:19 PM > To: Zeev Suraski > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: [PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] 4.2.3 > Well, my primary workstation was a 64-bit Alpha syst

[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] 4.2.3

> -Original Message- > From: Zeev Suraski [mailto:[EMAIL PROTECTED]] > Sent: Saturday, August 17, 2002 10:06 PM > To: Sascha Schumann > Cc: Xavier Spriet; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: RE: [PHP-QA] Re: [PHP-DEV] 4.2.3 > > > At 22:58 17/08/2002, Sascha Schumann wrote: > >

[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] 4.2.3

At 00:18 18/08/2002, Sascha Schumann wrote: > I've had at a look at the bug reports Sebastian Nohn pointed > out. None of these are major issues. Annoying, but nothing > which would qualify PHP as being "buggy as hell". Still, > having these fixes in 4.2.3 would be a definitive

[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] 4.2.3

I agree on every point. It's not "buggy as hell" but it's quite annoying and it puts the developer in a situation where many workarounds have to be made when these bugs are fixed in CVS... -Original Message- From: Sascha Schumann [mailto:[EMAIL PROTECTED]]

[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] 4.2.3

(sorry Zeev, I sent this reply only to you the first time) Sebastian Nohn is the one that has noticed most of the 64 bits related bugs I was refering to. I am sure he can give you more information of these bugs. It seems it was working fine just a few months ago. I experience some of them

[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] 4.2.3

On Sat, 17 Aug 2002, Zeev Suraski wrote: > At 22:58 17/08/2002, Sascha Schumann wrote: > > > 64-bit fixes (for whatever reason), I think that's quite alright. 64-bit > > > support is a major thing, which people, especially businesses, will not > > > really expect to be implemented in a bug-fix r

Re: [PHP-DEV] 4.2.3

Perhaps the "Status" field could be expanded so that bugs that are deemed necessary for the "stable" branch would follow a path like: open -> ... -> fixed in current -> merged to stable -> closed (or something like that) That way if a bug is fixed in "current", it will remain "open" until it

Re: [PHP-DEV] trans-sid warning?

> Any propagation, doesn't matter. > The passed id must exist, otherwise discarded and regenerated. > I saw that php already creates the session at the start. > > The possibility to count on a stable name, because recreable anytime > and though surviving gc, is a great weaknes for that tipe of sno

Re: [PHP-DEV] trans-sid warning?

On 02:45, sabato 17 agosto 2002, Rasmus Lerdorf wrote: > > Edin Kadribasic wrote: > > > > I absolutely agree with Stefan here. It is *not* PHP's job to > > > > > > secure > > > > > > > a connection. SSL does this. > > > > > > Like that's going to stop users from pasting url with SID in it > > > to

[PHP-DEV] Re: [Patch] PHP segv fix bug #17000

Nope, that's not a valid patch. zval_dtor() is not supposed to pay any attention to refcount's. It should be fixed at a different level, I'll check into it. Zeev At 22:58 17/08/2002, Ilia A. wrote: >Since there is no check if there is a refcount before freeing an object there >is a segv if t

[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] 4.2.3

At 22:58 17/08/2002, Sascha Schumann wrote: > > 64-bit fixes (for whatever reason), I think that's quite alright. 64-bit > > support is a major thing, which people, especially businesses, will not > > really expect to be implemented in a bug-fix release. > > 64-bit support has worked for year

[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] 4.2.3

> 64-bit fixes (for whatever reason), I think that's quite alright. 64-bit > support is a major thing, which people, especially businesses, will not > really expect to be implemented in a bug-fix release. 64-bit support has worked for years in PHP -- it is not new or a 'major thing'. As

[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] 4.2.3

At 22:28 17/08/2002, Xavier Spriet wrote: >This is quiteconcerning. >It appears the PHP release process is not suited to the way PHP is >developed anymore >and this can lead in severe inconsistencies. >What seemed to have happened is that several bugfixes were fixed in CVS >instead of the bugfix

[PHP-DEV] [Patch] PHP segv fix bug #17000

Since there is no check if there is a refcount before freeing an object there is a segv if the object gets freed. This segv can be caused by the following php code RCS file: /repository/Zend/zend_variables.c,v retrieving revision 1.42 diff -u -3 -p -r1.42 zend_variables.c --- zend_variables.c

[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] 4.2.3

This is quiteconcerning. It appears the PHP release process is not suited to the way PHP is developed anymore and this can lead in severe inconsistencies. What seemed to have happened is that several bugfixes were fixed in CVS instead of the bugfix release which if fine with me... but the bugs

[PHP-DEV] Re: #18655 [Bgs->Csd]: strtotime() with "next Sunday"

Yup, but it is one of those "clearly wrong" cases. On Sat, 17 Aug 2002, Derick Rethans wrote: > On 30 Jul 2002 [EMAIL PROTECTED] wrote: > > > Yeah, reading a bit more it looks like you are right. I have fixed > > this in CVS now. "next" maps to "2" now instead of "1" > > Doesn't this break bac

[PHP-DEV] Re: #18655 [Bgs->Csd]: strtotime() with "next Sunday"

On 30 Jul 2002 [EMAIL PROTECTED] wrote: > Yeah, reading a bit more it looks like you are right. I have fixed > this in CVS now. "next" maps to "2" now instead of "1" Doesn't this break backward compability? Derick > > > Previous Comments: > -

Re: [PHP-DEV] PHP apxs installs on AIX

On Sat, 17 Aug 2002, Dan Kalowsky wrote: >Hello again list... > >While scanning through some of the bugs tonight, I came across a real jem. > >A large number of bugs are submitted dealing with the fact that PHP on AIX >machines does not install. There is some minor hackery done to enable >this,

Re: [PHP-DEV] RE: [PHP-QA] RE: [PHP-DEV] 4.2.3

Because we aren't always sure what the next version will be. Witness the 4.0.6-4.0.7/4.1 release process. On Sat, 17 Aug 2002, Liz wrote: > > there should be 'fixed in the next bug-fix release' or 'fixed > > in the next > > semi-major release'. > > How about > > Will be fixed in version major

Re: [PHP-DEV] RE: [PHP-QA] RE: [PHP-DEV] 4.2.3

Isnt this what a bug/change log is for... If its not in the change log it wasnt put in yet. Just add a small comment at the top. "Not all changes currently in CVS may be in this release due to blah blah blah contraints" On Sat, 2002-08-17 at 11:19, Liz wrote: > > there should be 'fixed in the ne

[PHP-DEV] Php and CGI

With the increased functionality of PHP as non-web based lang has anyone looked into the possibility of making a more "compiled" package that doesnt require a seperate php binary.. Before someone goes off on the "If you want to do that use C" bit... I don't know C although im sure I could learn

[PHP-DEV] RE: [PHP-QA] RE: [PHP-DEV] 4.2.3

> there should be 'fixed in the next bug-fix release' or 'fixed > in the next > semi-major release'. How about Will be fixed in version major.minor.buildrelease ?? ie tell them which version it will be fixed in, no confusion at all then -- PHP Development Mailing List

Re: [PHP-DEV] 4.2.3

It's not a matter of what we call it - I thought it would make sense to release a new version based on the 4.2 branch, because 4.3 has TONS of new features and is thus very likely to introduce new inconsistencies and bugs. As people have said here several times in the last few weeks, most use

Re: [PHP-DEV] 4.2.3

Regardless of what we call it, we need to light a fire under people to get a new release out. The fixes are piling up in CVS. Stig, could you give us a status report? Do you still have time to push this release? -R On Sat, 17 Aug 2002, Zeev Suraski wrote: > Ok then, I retract my suggestion t

[PHP-DEV] Re: [PHP-QA] RE: [PHP-DEV] 4.2.3

At 17:52 17/08/2002, Sebastian Nohn wrote: >No! This simply confuses users! Someone reported a bug n weeks ago, this bug >"has been fixed in CVS" n-x weeks ago. Now there is a new release an WOW! >this bug is'nt fixed! Fixed in CVS means fixed in CVS and the user expects >this bug to be fixed in t

Re: [PHP-DEV] 4.2.3

Ok then, I retract my suggestion to release 4.2.3. Zeev At 17:59 17/08/2002, Dan Kalowsky wrote: >I disagree that it should go out as is, very strongly at that too. > >Some fixes not in the 4.2 branches: > >- ODBC no longer crashes on Windows upon unloading >- while not fully tested, ext/java no

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] 4.2.3

On Sat, 17 Aug 2002, Dan Kalowsky wrote: > I disagree that it should go out as is, very strongly at that too. I agree with Dan here. - Sascha -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] 4.2.3

On Sat, 17 Aug 2002, Zeev Suraski wrote: > PHP x.y.z has known bugs that are not fixed, for any given x, y and z, > since forever, and until the of time. Realize that, and decisions become > much simpler. Yes, but again many of these fixes were not applied to the 4_2 Branch because we had been

Re: [PHP-DEV] 4.2.3

I disagree that it should go out as is, very strongly at that too. Some fixes not in the 4.2 branches: - ODBC no longer crashes on Windows upon unloading - while not fully tested, ext/java now works for 1.4 JDK's - various memory leak fixes provied by Ilia (pack being one of them) - a few misc f

[PHP-DEV] CVS Account Request: 4441

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

Re: [PHP-DEV] Re: [PHP-DOC] Re: #3793 [Ana->Opn]: session.gc_maxlifetimedoes not work

That could work. Would require an extra callback for the custom session code. Basically a 'touch' callback would need to be added. But I suppose that would need to be added regardless to support readonly mode. -R On Sat, 17 Aug 2002, Zeev Suraski wrote: > Coming to think of it, how about: >

RE: [PHP-DEV] 4.2.3

Hi, > At 16:41 17/08/2002, Sebastian Nohn wrote: > >Why release a RC for a software that has some known bugs not fixed. > > PHP x.y.z has known bugs that are not fixed, for any given x, y and z, > since forever, and until the of time. Realize that, and decisions become > much simpler. > > Releas

Re: [PHP-DEV] Re: [PHP-DOC] Re: #3793 [Ana->Opn]: session.gc_maxlifetime does not work

At 16:54 17/08/2002, James E. Flemer wrote: >Would it be difficult to just add a "dirty" flag somewhere, Not really, because today people can modify the session data by simply changing $_SESSION. We have no way of detecting whether $_SESSION was changed, as it's just a regular variable (for th

RE: [PHP-DEV] 4.2.3

At 16:41 17/08/2002, Sebastian Nohn wrote: >Why release a RC for a software that has some known bugs not fixed. PHP x.y.z has known bugs that are not fixed, for any given x, y and z, since forever, and until the of time. Realize that, and decisions become much simpler. Releasing a new version

Re: [PHP-DEV] 4.2.3

I think it makes good sense to release 4.2.3 as-is (after a short QA cycle, that will ensure we didn't introduce any new bugs). If 4.2.3 becomes a larger project, with more pre-requisites, I don't see it happening ("if it will not be simple, it will simply not be"). The last time around 4.2.3

Re: [PHP-DEV] 4.2.3

> I'd like to raise the option of releasing 4.2.3 again. I believe that it > would be quite a while before 4.3.0 is out, and there are quite a few fixes > in the 4.2 branch that should make the userbase as soon as possible, > especially the Windows userbase. > I think that releasing 4.2.3 can be

Re: [PHP-DEV] Re: [PHP-DOC] Re: #3793 [Ana->Opn]: session.gc_maxlifetimedoes not work

Would it be difficult to just add a "dirty" flag somewhere, so that the session data only gets written out iff a variable has been added, removed, or changed? That way existing php code using sessions would have improved performance. Perhaps combine this idea with Zeev's idea of using 'touch'. I d

Re: [PHP-DEV] 4.2.3

I have to disagree, a LOT of bug fixes have gone in. Honest I can run through the list of things I think should be done, and a list of things that I think should be back ported. None of it is new functionality, all of it is fixes to bugs. And I still think the Tru64/AIX issues will need to be s

RE: [PHP-DEV] 4.2.3

Why release a RC for a software that has some known bugs not fixed. This leads to a RC1, RC2, RC3 and so on. If you only want to fix thw windows bugs you stated, a 4.2.3 would be useless to me, in this case I vote against a 4.2.3 as this would delay 4.3.0 just a little bit more. > From: Zeev Sura

RE: [PHP-DEV] Tru64, snprintf and bug #1298

Maybe U should say that I use gcc (2.9) under Tru64, the other thing is that I've experienced most bugs also under Linux/Alpha and FreeBSD/Alpha, so I think it's 64-bit in most cases. > -Original Message- > From: Dan Kalowsky [mailto:[EMAIL PROTECTED]] > Sent: Saturday, August 17, 2002 5:

Re: [PHP-DEV] 4.2.3

I'd really like to avoid waiting this time, though (the enemy of good is better...). Even if we release 4.2.3 as it is in the branch, without any further fixes, it's significantly better than 4.2.2. Translating this into action - my personal preference is to release the RC as early as tomorro

Re: [PHP-DEV] 4.2.3

Hrm, well a lot of the fixes I've been doing have only gone to head because the belief of no 4.2.3. There are still a few outstanding bugs I'd like to see fixed before things we RC. Sfox and I (mostly her though) have been looking at the dbm_* functionality on Windows. We're questioning if it e

RE: [PHP-DEV] 4.2.3

Hi, > I'd like to raise the option of releasing 4.2.3 again. I believe that it > would be quite a while before 4.3.0 is out, and there are quite a > few fixes > in the 4.2 branch that should make the userbase as soon as possible, > especially the Windows userbase. > I think that releasing 4.2.3

Re: [PHP-DEV] Re: [PHP-DOC] Re: #3793 [Ana->Opn]: session.gc_maxlifetime does not work

Coming to think of it, how about: (a) Always use mtime (b) 'touch' the file in case of session-readonly That would allow users to have the performance benefit of noatime for all of the files on the filesystem, except for the session files. 'touch'ing the file should take about the same time a

Re: [PHP-DEV] Re: [PHP-DOC] Re: #3793 [Ana->Opn]:session.gc_maxlifetime does not work

On Sat, 2002-08-17 at 12:36, Zeev Suraski wrote: > Well, I guess it boils down to whether we want to support this function > (which should be easy, I think), or support filesystems without atime. I > vaguely remember that many filesystems don't have (or are capable of > disabling) atime for pe

[PHP-DEV] Predefined Classes in Zend2

Hi, is it possible that predefined classes no longer working in zend2 engine ? eg: in zend1: the incomplete message is written: Fatal error: The script tried to execute a method or access ... correct, but in zend2: object(__PHP_Incomplete_Class)(0) {} also the same example with ming: in z

Re: [PHP-DEV] Re: #18401 [Opn->Ana]: shuffle() broken (fwd)

Damn. This is a text book type of problem... Thanks for reminding :) -- Yasuo Ohgaki Tim Converse wrote: > --- Yasuo Ohgaki <[EMAIL PROTECTED]> wrote: > >>Tim Converse wrote: >> >>>--- Yasuo Ohgaki <[EMAIL PROTECTED]> wrote: >>> >>> Dan Kalowsky wrote: >Anyone able to confirm

Re: [PHP-DEV] 4.2.3

On Sat, Aug 17, 2002 at 01:47:19PM +0300, Zeev Suraski wrote: > I'd like to raise the option of releasing 4.2.3 again. I believe that it > would be quite a while before 4.3.0 is out, and there are quite a few fixes > in the 4.2 branch that should make the userbase as soon as possible, > especi

[PHP-DEV] 4.2.3

I'd like to raise the option of releasing 4.2.3 again. I believe that it would be quite a while before 4.3.0 is out, and there are quite a few fixes in the 4.2 branch that should make the userbase as soon as possible, especially the Windows userbase. I think that releasing 4.2.3 can be done wi

[PHP-DEV] Re: [PHP-DOC] Re: #3793 [Ana->Opn]: session.gc_maxlifetime does not work

Ok, that makes sense. I like the idea of being able to configure whether you want to use mtime or atime, so that non atime-compliant filesystems can still be supported, but we leave the window to support session-readonly in the future. Zeev At 07:37 17/08/2002, Rasmus Lerdorf wrote: >Ok, thi

[PHP-DEV] Re: [PHP-DOC] Re: #3793 [Ana->Opn]: session.gc_maxlifetime does not work

Well, I guess it boils down to whether we want to support this function (which should be easy, I think), or support filesystems without atime. I vaguely remember that many filesystems don't have (or are capable of disabling) atime for performance reasons, but I could be wrong. But, if that's

[PHP-DEV] Re: ZE2 and PHP

> 2. When is it expected to be available in a development (experimental) or > production release? it already is - zend 2 alpha2: http://www.php.net/do_download.php?download_file=php-4.3.0-dev-zend2-alpha2. tar.gz rash -- PHP Development Mailing List To unsubscribe, visit