Re: [PHP-DEV] Question for Zeev, Zak or Georg - mysql_query andpossible integer overflow?

[Wez Furlong]

Hi Matt,

Yes, there is a risk of overflow.
>From my understanding, the id is signed, so you will hit overflow at 2G
rather than 4G resources.
This applies to any/all PHP/ZE resources.

I'm not sure what happens when it overflows; it seems like the query
would fail.

You could design your application so that it re-runs itself when the
query fails (pcntl_exec(), or one of the other execution functions).

--Wez.

On Tue, 25 Mar 2003, Matt Flaherty wrote:

> Hi,
>
> I have a question for the authors of the mysql extension. I'm sure you
> gentlemen are very busy, but I'd appreciate your insight if you can
> spare a moment. I'm developing a stand-alone php application running in
> an infinite loop from the command line interface. A mysql database is
> polled continually for new rows to deal with. The same query is executed
> several times in one second. I've noticed that whether or not a query
> resource is freed the next query identifier returned from mysql_query()
> is ++ the last one. I'm sure this is by design and governed by the mysql
> driver. Naturally I'm concerned about integer overflow when the the
> application has been running uninterrupted for a very long time. I don't
> think I can wait around while a test script runs to see what happens
> after 4,294,967,295 is exceeded though! Can anyone tell me with
> certainty or hazard a guess what might happen here? I thank you very
> much for your time.
>
> Matt
>
> ps - I'm doing this through PEAR::DB::mysql
> --
> Matt Flaherty <[EMAIL PROTECTED]>
> Boltblue International Ltd.
>
>
> --
> 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] 64bit PHP on solaris

[Wez Furlong]

On Sat, 15 Mar 2003, James Devenish wrote:
> Regardless of what you personally understand (and what I personally
> understand), my point would be that the problems are simply unfixed
> by *anyone*.

This is the first time that anyone has brought this issue to my
attention.

> Index: main/streams.c
> ===
> RCS file: /repository/php4/main/Attic/streams.c,v
> retrieving revision 1.125.2.37
> diff -u -u -r1.125.2.37 streams.c
> --- main/streams.c6 Mar 2003 20:58:19 -   1.125.2.37
> +++ main/streams.c8 Mar 2003 10:48:16 -
> @@ -1532,7 +1532,7 @@
>   }
>   if (ret) {
>   fflush(data->file);
> - *ret = (void*)fd;
> + *(int*)ret = fd;
>   }
>   return SUCCESS;
>   default:

> What have I done? Well, someone's taking fd (declared as an 'int', which
> ...

There is no need for a patronizing tone here; I can read C code.

I will commit this fix shortly.  Are there any other places in the
streams code that are similarly affected?

--Wez.

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

Re: [PHP-DEV] 64bit PHP on solaris

[Wez Furlong]

On Fri, 14 Mar 2003, David Hill wrote:
> > Please coordinate with me on streams issues; if some 64bit oses declare
> > descriptors as longs rather than ints, then we could have a bigger job
> > on our hands (similar to the mess with socket types under win32).
>
> Tru64 & HP-UX (and I would guess Solaris and the rest) - the descriptor is
> an int, which is part of the problem because the streams code in 4.3 casts
> it wrong.
>
> James sent me a patch that included a cast fix, but I have yet to submit it
> (or try too) because I got caught up in trying to follow the code and then
> got diverted. I will endevor to finish my look at the patch  and see if Jani
> will let me commit it.

Which part of "please coordinate with me on streams issues" didn't you
get? ;-)

If there are long vs int issues in streams, please let me know where
they are and I will fix it.

Thanks :)

--Wez.

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

Re: [PHP-DEV] 64bit PHP on solaris

[Wez Furlong]

Please coordinate with me on streams issues; if some 64bit oses declare
descriptors as longs rather than ints, then we could have a bigger job
on our hands (similar to the mess with socket types under win32).

--Wez.

On Fri, 14 Mar 2003, David Hill wrote:

> > CRIPES, people! I posted patches in November 2002 (admittedly, it was a
> > large patch and probably no one got to check it all out). Then, I
> > reposted them (and sent then directly to you, Dave!) a few days ago.
>
> And I got all but the three files merged that are probably causing his
> problem too - sigh-
>
> Sorry but I don't commit what I don't understand, and the three streams
> files needed some more understanding on my part. In those areas the php5
> head differs quite a bit from the 4_3 stream.
>
> And on top of that I got diverted by a bug in the session stuff too.
>
> Well as I always say in my volunteer posts - if you don't like the job I am
> doing - cut my pay, if you like what I am doing you can double it - either
> way the result is the same :-)
>
> I will try to get the file descriptors stuff in by early next week.
>
> Dave
>
>
>

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

Re: [PHP-DEV] 64bit PHP on solaris

[Wez Furlong]

Of the PHP_4_3 branch?

Could you open a bug report for each of these three issues at
bugs.php.net?

--Wez.

On Thu, 13 Mar 2003, Chris Field wrote:

> I am working off a checkout from about three days ago...
>
> On Thu, 2003-03-13 at 11:21, Wez Furlong wrote:
> > Make sure that you are using the latest stable snapshot from
> > http://snaps.php.net; a number of 64bit issues have already been addressed.
> >
> > --Wez.
> >
> > On Thu, 13 Mar 2003, Chris Field wrote:
> >
> > > We have been attempting to run php on a brand new sun v880, and have had
> > > a number of problems.
> > >
> > > first file_get_contents & readfile both core dump with bus errors b/c
> > > the file descriptors are typed as int's when they should be longs
> > > (steams.c lines 1020/1156)
> > >
> > > second, and far stranger is when you open a file with the mode 'a' it
> > > opens it the does a seek using SEEK_CUR which leaves the file pointer at
> > > the beginning of the file, shouldn't that bee a SEEK_END?  Altering that
> > > results in expected functionality, will it break anything else?
> > >
> > > third, and even stranger, is in php_spn_common_handler it calls:
> > > zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "ss|ll", &s11,
> > >   &len1, &s22, &len2, &start, &len)
> > >
> > > the va_list has the correct values for the length of the two strings
> > > passed in, however the lengths are never assigned into len1 and len2, as
> > > it seems they should be.  Any ideas about why this is, I am kind of at a
> > > loss, in the mean time I simply set the lengths of the two strings in
> > > php_spn_common_handler after the parse_parameters function returns which
> > > fixes it.

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

Re: [PHP-DEV] 64bit PHP on solaris

[Wez Furlong]

Make sure that you are using the latest stable snapshot from
http://snaps.php.net; a number of 64bit issues have already been addressed.

--Wez.

On Thu, 13 Mar 2003, Chris Field wrote:

> We have been attempting to run php on a brand new sun v880, and have had
> a number of problems.
>
> first file_get_contents & readfile both core dump with bus errors b/c
> the file descriptors are typed as int's when they should be longs
> (steams.c lines 1020/1156)
>
> second, and far stranger is when you open a file with the mode 'a' it
> opens it the does a seek using SEEK_CUR which leaves the file pointer at
> the beginning of the file, shouldn't that bee a SEEK_END?  Altering that
> results in expected functionality, will it break anything else?
>
> third, and even stranger, is in php_spn_common_handler it calls:
> zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "ss|ll", &s11,
>   &len1, &s22, &len2, &start, &len)
>
> the va_list has the correct values for the length of the two strings
> passed in, however the lengths are never assigned into len1 and len2, as
> it seems they should be.  Any ideas about why this is, I am kind of at a
> loss, in the mean time I simply set the lengths of the two strings in
> php_spn_common_handler after the parse_parameters function returns which
> fixes it.
>
>
> --
> Chris Field
> [EMAIL PROTECTED]
> Affinity Solutions Inc.
> 386 Park Avenue South
> Suite 1209
> New York, NY 10016
> (212) 685-8748 ext. 32
>

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

Re: [PHP-DEV] Re: Opening files for write from php modules

[Wez Furlong]

Even so, its a very good idea to use streams for this; you will
automatically make your extension safe_mode and open_basedir aware,
virtual cwd aware and be able to avoid crippling limitations of certain
OS (eg: Solaris can only fopen 256 files).

These things are particularly important in a web server environment.

--Wez.

On Mon, 10 Mar 2003, Scott Baker wrote:

> Nevermind... Seems the webserver was on afs filespace, and apache/php
> didnt like the permissions it had there.  Everything works now that I
> moved it to a jfs filesystem.
>
> Scott Baker wrote:
> > I'm trying to write an extention that calls a C++ lib i've written. I've
> > gotten the module to compile and function mostly correctly, but I have a
> > problem opening files for writing within functions of the lib. My code
> > links libpng to write image files to a img directory on the webserver.
> > The problem is that any attempt to actually open a file for write fails:
> >
> >
> > this is the code to open the file (standard stuff):
> >
> > FILE *pngout
> > pngout = fopen(filename, "wb");
> >
> > if (pngout==NULL) {
> > fprintf(stderr,"ERROR: Unable to open file %s for writing
> > graph\n",filename);
> > return -1;
> > }
> >
> > This code works when i compile the lib as a stand-alone app, but fails
> > when I call it from php.  I doubt permissions are the issue, I've gone
> > as far as to chmod 777 the img dir it writes to, and I still get this
> > error.  Is the problem that I need to use php streams to write to disk
> > or something?  I'd like to be able to use the same lib linked into a php
> > module and into a stand alone app.
> > Thanks.
> >
> >
> >
> > Platform: PowerPC AIX 4.3.3. ml10
> > Compiler: xlC  (the C++ one)
> > PHP version: 4.0.6 (this is because this was the most resent IBM rpm for
> > aix.  I had compile problems with newer versions, though i think b/c of
> > the changes i've made to libtool, it should work now.) I had to edit
> > libtool to use xlC's makeC++SharedLib script to get the module to link
> > correctly.  I've compiled everything from my library to php to apache
> > with xlC.
> >
>
>
> --
> 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] Language Auto Detection / www.php.net

[Wez Furlong]

Perhaps because he prefers to read most sites in his native language?

--Wez.

On Mon, 10 Mar 2003, Mincu Alexandru wrote:

> why not set your browser accept language to english?

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

Re: [PHP-DEV] bug in zend_API.c (with patch)

[Wez Furlong]

On Sat, 7 Mar 2003, Eric Lambart wrote:

> > Adding strtolower calls will only slow down the whole language.

> but my
> point is the overhead involved cannot possibly rival the amount already
> created by the zend_str_tolower() calls within zend_execute.c, which is
> surely encountered far more often in everyday use of PHP.
>
> Does what I am suggesting make sense, now?

Yes, but simple maths suggests that adding a strtolower call when
building the initial hash for each of 2837 functions is surely slower
than not having it :) (this is just for extensions in the core).

You have to remember that this cost is incurred each time php is loaded;
a big performance hit for people using CGI for example.

> But as I have seen no warnings or admonitions about using one or more
> upper case letters in a function or class name in the available
> extension-writing documentation (either online, or in the book ...

Consider this thread a warning ;-)

--Wez.

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

Re: [PHP-DEV] bug in zend_API.c (with patch)

[Wez Furlong]

It's not a bug; PHP is a case-IN-sensitive language when it comes to
function and class names.

Adding strtolower calls will only slow down the whole language.

Using lowercase function and class names is the best solution.

--Wez.

On Fri, 7 Mar 2003, Eric Lambart wrote:

> On Fri, 2003-03-07 at 14:24, Brad LaFountain wrote:
> > Why can't you just simply name your classes all lowercase.
>
> Because then I wouldn't have discovered the bug! =)

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

Re: [PHP-DEV] Specifying pass-by-ref parameters

[Wez Furlong]

Look at the function table in basic_functions.c:

{ PHP_FE(nameoffunc),   NULL }

This NULL can be replaced with an array that specifies BYREF_FORCE for
the relevant arguments; look for first_and_second__args_force_ref for an
exmaple.

--Wez.

On Fri, 7 Mar 2003, l0t3k wrote:

> im a bit rusty, so could someone explain how i would set up a function to
> accept a byref parameter ? no zend api documentation i ran across is clear
> on this issue.
>
> 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

[PHP-DEV] Re: main/network.c

[Wez Furlong]

Hi marcus,

Moriyoshi is going to revert the HAVE_INET_NTOP part;
I have to go out now, so I won't be able to address the warnings right
away, but will look at them later.

--Wez.

On Sat, 1 Mar 2003, Marcus [iso-8859-1] Börger wrote:

> Hi Wez,
>
> i cannot compile current network.c. The following patch fixes two warnings
> and one error
> but one warning is left:
> /usr/src/php4-HEAD/main/network.c: In function `php_network_accept_incoming':
> /usr/src/php4-HEAD/main/network.c:608: warning: `error' might be used
> uninitialized in this function
>
> If i understand code and message correct - then indeed this could be a real
> error because it is possible to return an uninitialised error code there.
>
> since you're the one knowing the correct default error codes i leave it up
> to you :-)
>
> regards
> marcus
>
> Index: main/network.c
> ===
> RCS file: /repository/php4/main/network.c,v
> retrieving revision 1.95
> diff -u -r1.95 network.c
> --- main/network.c  28 Feb 2003 21:03:36 -  1.95
> +++ main/network.c  1 Mar 2003 15:48:30 -
> @@ -434,6 +434,7 @@
>  break;
>  default:
>  /* Unknown family */
> +   socklen = 0; /* fix warning */
>  sa = NULL;
>  }
>
> @@ -493,7 +494,7 @@
>  }
>
>  if (textaddr) {
> -#if HAVE_IPV6 && HAVE_INET_NTOP
> +#if HAVE_IPV6
>  char abuf[256];
>   #endif
>  char *buf = NULL;
> @@ -711,6 +712,7 @@
>  break;
>  default:
>  /* Unknown family */
> +   socklen = 0; /* fix warning */
>  sa = NULL;
>  }
>
>
>
> --
> --
> 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] date() extension

[Wez Furlong]

You don't need any of that stuff to read the guidelines for submitting a
patch - why don't you just read it and save everybody some time...

--Wez.

On Fri, 28 Feb 2003, Dirkjan Ochtman wrote:

> Please! It's just a date() parameter, about 20 lines of code, mostly taken
> from another date() parameter. I'm a Windows user, I don't have all your
> cool auto* and gcc stuff. It doesn't seem worthwhile for me to go through
> installing Cygwin for something this simple... Just reject the patch, if you
> don't want it.


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

Re: [PHP-DEV] date() extension

[Wez Furlong]

If you don't have time to support your own patch, why should we commit
it to CVS!??

There is a reason for that doc being there; please read it.

--Wez.

On Thu, 27 Feb 2003, Dirkjan Ochtman wrote:

> Didn't have time, but here's a new patch.
>
> Regards,
>
> Dirkjan
>
> "Wez Furlong" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > Please read the README.SUBMITTING_PATCH file in the root of the php
> > source and re-submit your patch.
> >
> > On Mon, 17 Feb 2003, Dirkjan Ochtman wrote:
> >
> > > begin 666 datetime.c
> >
>
>
> begin 666 iso8601diff.txt
> [EMAIL PROTECTED](&1A=&5T:6UE+F,-"CT]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
> M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T-"E)#

Trimmed crapola uuencoded attachment.


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

Re: [PHP-DEV] Getting an external param into a userspace streamsfilter...

[Wez Furlong]

Hi David,

user filters are in a little bit of flux atm.

However, the idea is that the param argument will be altered to be a
zval (rather than just a string).

In the oncreate() method, the following member variables are available
to the filter:

string $this->filtername; // name of the filter
mixed $this->params;  // params passed from prepend/append func

Hope this helps; please only use current CVS for PHP 5 for playing
around with this stuff; if you run into problems let me (and Sara
<[EMAIL PROTECTED]>) know and we can sort them out.

--Wez.

On Thu, 27 Feb 2003, David Brown wrote:

> On Thu, Feb 27, 2003 at 09:42:24AM -0500, David Brown wrote:
> | On Thu, Feb 27, 2003 at 09:40:15AM -0500, David Brown wrote:
> | | Hi Wez, everyone:
> | |
> | | Is there (or will there ever be) a good way to transmit an extra
> | | parameter into a php_user_filter around the time that oncreate() is
> | | called? I've run into a couple cases where it'd be incredibly useful
> |
> | Nevermind. Seems I can't read this morning. Sorry about that.
>
> Well, perhaps I jumped to self-chastisement a bit too quick. There's a
> single string parameter that can be passed to stream_filter_append /
> stream_filter_prepend, but how would one retrieve this information once
> inside of the filter? Moreover, for passing arbitrary zvals in, would I
> have to resort some hackery using array keys from a global, or is there
> an easier way?
>
> Thanks in advance,
>
> - Dave 'Replies to self way too many times'
>   [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] Flex never-interactive mode

[Wez Furlong]

On Wed, 26 Feb 2003, Andi Gutmans wrote:

> 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
 ^

Yes, this is a good idea - INI files are never interactive.

--Wez.


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

Re: [PHP-DEV] Performance degradation part 2 the module version

[Wez Furlong]

On Mon, 24 Feb 2003, Rasmus Lerdorf wrote:

> if (stream) {
> if (self->is_pipe) {
> stream->flags |= PHP_STREAM_FLAG_NO_SEEK;
> } else {
> stream->position = ftell(file);
> }
> }
>
> We should be able to skip that ftell() call on a script or include file we
> have just opened, right?

Yes; prior to my fixes this week, the ftell was sometimes important;
streams should be able manage just fine without it now.

> _php_stream_open_wrapper_as_file() what are you trying to guard against
> with that stream_cast call?
>
> if (php_stream_cast(stream, 
> PHP_STREAM_AS_STDIO|PHP_STREAM_CAST_TRY_HARD|PHP_STREAM_CAST_RELEASE,
> (void**)&fp, REPORT_ERRORS) == FAILURE)
> {
> php_stream_close(stream);
> if (opened_path && *opened_path)
> efree(*opened_path);
> return NULL;
> }
>
> We have already stat()'ed the file to death.  We know it is there, that we
> are allowed to open it, etc.  What could go wrong that the open call just
> above it wouldn't have caught?  Is it just a case of getting too general
> and we need a special-case simpler function for the most common operation
> of simply opening script files?

Yes and no. (we need this approach in order to be able to
include/require from any wrapper).

In php_stream_cast, we need to ensure that when we pass back the file
pointer, it is seeked to the correct offset (as we see it) in the file.
This is because the underlying FILE* has its own buffer, and its own
idea of the file position.

[Yes, using FILE*/stdio streams with buffers is causing headaches, which
is why I'm moving away from them in PHP 5].

Admittedly, when opening the file for the first time, we do not need to
seek - so we can avoid it by passing a flag (OR'd with the REPORT_ERRORS
flag).

I'm sure we can eliminate those seeks.  Are there any other areas in the
streams code that you can see that could do with a syscall tune-up?

--Wez.


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

Re: [PHP-DEV] extra realpath() found

[Wez Furlong]

With my ze-stream patch to PHP 5 (in HEAD now), this can be avoided as
all files opened on the behalf of the engine can be managed via a single
function, provided that they set the zend file handle to open via a
filename.

--Wez.

On Mon, 24 Feb 2003, Sander Roobol wrote:

> On Sun, Feb 23, 2003 at 01:25:34PM -0800, Rasmus Lerdorf wrote:
> > Hey Sander, you fixed a problem back in July where you introduced a second
> > realpath() call into the main execute_script() function.
> > [...]
> > php_fopen_primary_script() calls expand_filepath() which does the realpath
> > before we get to execute_script.  Why not add the path to the
> > included_files list at that point instead?
> >
> > Let me know if you feel like playing with it, otherwise I will.
>
> I looked into it briefly, as I don't have much time currently, but I
> discovered it's not that easy. php_fopen_primary_script() is only used
> by the CGI and Servlet SAPI, while all SAPIs call php_execute_script().
> We need to find a different place to update the included_files list, or
> make sure the SAPIs don't call realpath() themselves.
>
> I think it's better if someone with some more experience with PHP's
> internals looks into this, because it will take me too much time right
> now.
>
> Sander
>
> --
> 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

[Wez Furlong]

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 
> 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] Performance degradation part 2 the module version

[Wez Furlong]

This double seeking is most probably due to the fact that the stdio
layer does one set of seeking, whereas streams needs to do another.

This can be solved by moving away from using stdio for streams, and just
using the "raw" descriptors instead.  (already made a start on this in
PHP 5).

I'm a little unsure if we should apply equivalent changes to the branch
(given our release policy), but I share your concerns for performance.

Ilia and I have discussed implementing some kind of fstat cache for use
by the "plain file" streams.  However, we are nowhere near implementing
this, yet alone certifying it safe for inclusion in the branch.

Have you been testing PHP_4_3 from CVS or the actual 4.3.0 release?
You might find the situation slightly better using the latest (I tidied
up some seek related issues the other day).

--Wez.

On Sun, 23 Feb 2003, Rasmus Lerdorf wrote:

> In 4.3 we have:
>
> _llseek(4, 0, [0], SEEK_CUR)= 0 <0.09>
> lseek(4, 0, SEEK_SET)   = 0 <0.09>
> brk(0)  = 0x81a8000 <0.08>
> brk(0x81a9000)  = 0x81a9000 <0.11>
> ioctl(4, SNDCTL_TMR_TIMEBASE, 0xbfffd190) = -1 ENOTTY (Inappropriate ioctl for 
> device) <0.09>
> brk(0)  = 0x81a9000 <0.07>
> brk(0x81aa000)  = 0x81aa000 <0.09>
> read(4, "\n\n
> read(4, "", 4096)   = 0 <0.08>
> read(4, "", 8192)   = 0 <0.09>
> ioctl(4, SNDCTL_TMR_TIMEBASE, 0xbfffc150) = -1 ENOTTY (Inappropriate ioctl for 
> device) <0.08>
> close(4)= 0 <0.10>
> munmap(0x402ba000, 4096)= 0 <0.14>
>
> I really don't understand the SEEK_CUR there.  We're seeking forward 0
> bytes from the current location followed directly by a SEEK_SET back to 0?
> Is this streams overhead or something?  Wez?
>
> >From there on the requests are similar.  The alarm(0) calls right after
> alarm(300) could probably be skipped in both cases.
>
> Anyway, I will go after all these extra lstat/fstat calls and fix that,
> but I would appreciate some help with the setitimer() and weird seeking
> stuff.


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

Re: [PHP-DEV] file_put_contents() / file_add_contents() ?

[Wez Furlong]

Look in the archives for that guys original patch; it allowed doing
something like this:

$foo = array();

$foo[] = "some text";
$foo[] = "more text";

file_put_contents("file.txt", $foo);

and also:

file_put_contents("file.txt", $foo, $bar, $baz);

I'm not 100% sure if we want this feature, but perhaps it is worth
revisiting that patch.

--Wez.

On Thu, 20 Feb 2003, Ilia A. wrote:

> On February 20, 2003 02:51 pm, Sara Golemon wrote:
>
> > Was it decided not to create these?
>
> Yes
>
> > Is it simply a matter of noone having gotten around to it?
>
> Yes
>
> > Am I paying too much attention to the voices in my head?
>
> Maybe ;)
>
>
> Joking aside, I do have a patch to implement the mentioned functionality at
> http://bb.prohost.org/file2.txt. If there are no objections I'll commit this
> to the CVS tommorow.
>
> 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] date() extension

[Wez Furlong]

Please read the README.SUBMITTING_PATCH file in the root of the php
source and re-submit your patch.

--Wez.

On Mon, 17 Feb 2003, Dirkjan Ochtman wrote:

> begin 666 datetime.c


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

Re: [PHP-DEV] [PATCH] make the win32 project working again afterdate_sun*()'s

[Wez Furlong]

I'll do this now.

On Mon, 17 Feb 2003, moshe doron wrote:

> http://212.199.221.100/moshe/win32project-sunfuncs.patch.txt
>
> --
>
>


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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / run-tests.php /ext/curlinterface.c streams.c /ext/fbsql php_fbsql.c /ext/ftp ftp.c /ext/hyperwavehg_comm.c hw.c /ext/imap php_imap.c /ext/ldap ldap.c /ext/

[Wez Furlong]

Should be fixed now.

If any more of these occur, the problem is that  needs to be
included before  (which itself includes ).
I noticed that some source files include the winsock headers twice, so
there is probably some spring cleaning that can be done.

I have included  as one of the first things in , so
the large majority of all other .c files probably don't even need to
include it explicitly anymore.

--Wez.

On Sun, 16 Feb 2003, Sebastian Bergmann wrote:

> Wez Furlong wrote:
> > Log:
> > A add much more useful select(2) implementation than is provided by
> > windows sockets.
>
>   This broke the build for me.
>
>   I get 1500+ errors that look like this one:
>
> c:\programme\microsoft sdk\include\winsock2.h(2478): error C2375:
> 'WSAAsyncGetHostByName': Redefinition; different binding;
> c:\programme\microsoft sdk\include\winsock.h(925):
> See declaration of 'WSAAsyncGetHostByName'
>
> --
>   Sebastian Bergmann
>   http://sebastian-bergmann.de/ http://phpOpenTracker.de/
>
>   Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
>
> --
> 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] repost: return_value getting corrupted in extension

[Wez Furlong]

Hi Eric,

It really just sounds like you have some bug in your code where your
pointers are misbehaving.

All I can suggest is that you look very carefully at each pointer in the
relevant code to make sure it is ok.  Also, try stripping it down a
couple of lines at a time (by commenting them out) to see which ones are
making the difference.

There is not much that anyone on the list can do to help you here; it's
your code, only you have this problem and everyone elses code works just
fine.

Sorry that we can't help,

--Wez.

On Fri, 14 Feb 2003, Eric Lambart wrote:

> At this point, can anyone give me any reason to doubt that the problem
> lies within the Zend engine?  Please refer to my earlier posts on this
> thread for more (though less-informed and -investigated) details.

I doubt it is in the ZE, since it happens to be working very well for a
large number of users worldwide... :)

> This is all very strange to me, ESPECIALLY the 11th-character thing.

Most likely a coincidence of pointers and their position on stack.
Eg: adding another int variable to the locals in one of your functions
might change it from the 11th to the 11 + sizeof(int) character.



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

Re: [PHP-DEV] repost: return_value getting corrupted in extension

[Wez Furlong]

Hi Eric,

return_value is already allocated for you in a PHP_FUNCTION() that is
called by the engine (or via call_user_fuction(_ex)), as you have
guessed.

> PHP_FUNCTION(eo_table)

Looks correct.

>   /* call the constructor */
>   if ( call_user_function(NULL, &object, ctor_fn, ctor_retval, 0, NULL)

Looks correct too.  However, I would use call_user_function_ex, which
relieves you of the burden of creating a retval (among other things).

> > Hints: make sure that your zvals are correctly initialized (there are
> > some big differences between ALLOC_ZVAL and MAKE_STD_ZVAL).
>
> One resets the refcount and the is_ref flag, the other doesn't.  All the
> variables I'm dealing with are "fresh", not references to pre-existing
> zvals.

Yes, and this is important when the zval is passed into the engine
again.  If those flags and refcounts are incorrect, you will experience
problems like those you have described.  However, from what you have
shown here, it looks like your code is correct.

> Note also that the variables which are getting corrupted are simple
> strings, not even zvals.  Here is how I'm setting the value of serverId,
> which is one of those getting corrupted:
>
> add_property_string(return_value, "serverId", serverId, TRUE);
> efree(serverId);

In this case, it is better to do this:

add_property_string(return_value, "serverId", serverId, FALSE);

and not use the serverId again.

You need to specify TRUE if:

- the data was not allocated with the PHP memory allocator
  - the data is constant.
  - the data is on the stack.
  - the data was allocated with malloc
- the data is "owned" by some other zval or object that expects to efree
  it.

> Thanks in advance for any insights you can give.  This is really
> frustrating.  If you want to know how I am doing anything else, let me
> know.

Did you --enable-debug in your development build?  If not, I strongly
recommend that you do, as it will help detect overruns in emalloc'd
memory.  This is a great way to track down the lines of code that are at
fault.

The other thing to try is valgrind - it is possible that some of your
non-zend-api code is misbehaving, and valgrind will help you find that
problem code.

--Wez.


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

Re: [PHP-DEV] repost: return_value getting corrupted in extension

[Wez Furlong]

No offense, but this is really quite a useless problem report.
You are not showing any of the zend API that you use to create the
object, so how can we help you?

Hints: make sure that your zvals are correctly initialized (there are
some big differences between ALLOC_ZVAL and MAKE_STD_ZVAL).

Other things to try are looking at other extensions that create objects.
In the 4.3 release, the user-space streams creates objects and call their
constructors, so take a look at that code for some hints.

If you are returning strings, make sure that any that need to be
duplicated are duplicated etc. etc.

Using the source is your best option if you don't want (or are not
allowed) to show us your source.

The zend api docs http://www.php.net/manual/en/zend.php, although not
complete, should be good enough for what you need to do.

--Wez.

On Tue, 11 Feb 2003, Eric Lambart wrote:

> Hello all,
> I have scoured the php.dev group, reading most of the messages I could
> find regarding extensions and modules, but could not find any other
> reports of this problem anywhere.  I have a feeling there is an obvious
> answer.
>



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

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

[Wez Furlong]

Hey Ilia,

Lets also have either an enum or some real #define'd constants for the
values used in the C code.

eg:

REGISTER_LONG_CONSTANT() and the code that checks for a number should
both be using a symbolic constant rather than a hard-coded number.

--Wez.

On Mon, 10 Feb 2003, Ilia A. wrote:

> Attached is the proposed solution.
>
> Ilia


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

Re: [PHP-DEV] proc_open() patch

[Wez Furlong]

Hi Shane,

Looks good to me.  I will test it later this week, but it doesn't look
like there will be any problems.

--Wez.

On Sun, 9 Feb 2003, Shane Caraveo wrote:

> The attached patch adds 2 optional parameters to proc_open().  The
> first, cwd, and the second is an array for executing with a custom
> environment.  I've tested this on w2k and osx.  Comments, fixes,
> changes, and testing on Linux, would be appreciated.
>
> Shane
>


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

[PHP-DEV] ChangeLog again

[Wez Furlong]

ChangeLog ChangeLog ChangeLog ChangeLog :)

Anyone want to look into kicking the script and archiving the 2002
entries as a .gz ?

--Wez.


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

[PHP-DEV] Re: php4 . cant compile . ext/standard/var.c

[Wez Furlong]

Make sure you have the correct set of working files:

For PHP 5:

cvs co php5

For PHP 4.3-dev

cvs co -r PHP_4_3 php4

Checking out php4 HEAD is not supported.

--Wez.

On Sat, 8 Feb 2003, Lukas Schroeder wrote:

> hi wez,
>
> i'm currently trying to compile cvs head. there are quite a lot of
> missing definitions in there. one of them is Z_OBJ_HANDLER +
> get_class_name in /ext/standard/var.c
>
> the failing code has been committed by you on 2003-02-01
> (http://marc.theaimsgroup.com/?l=php-cvs&m=104407155303062&w=2)
>
>
> could you please check whether you have forgotten to commit these
> definitions?
>
> (i already tried a clean checkout; to no avail.
>
>
>
> regards,
>   -lukas
>
>
>


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

Re: [PHP-DEV] http streams can't be filtered?

[Wez Furlong]

It should not happen, and there is code in the http opener that *should*
avoid this, because it has negative implications for including files via
http.

I will take a look when I have more time...

--Wez.

On Wed, 5 Feb 2003, Sara Golemon wrote:

> Wez,
>
>   After our short discussion in IRC today I decided to try and put together
> a simple implementation of that filter wrapper.  What I came up with can be
> seen here: http://frankenbox.alphaweb.net/test/php.filter.diff.txt but it's
> not something I'm suggesting be commited, just a quick exercise to open my
> brain to thinking about implications... There's also the fact it's working
> on the current single filter chain model rather than the asymetric filter
> chains you've got planned.
>
>   Now, the point I've managed to completely skirt around I discovered
> something a little disturbing about the http wrapper (and presumably other
> network wrappers as well).  The following script (with or without the above
> patch applied) will *NOT* uppercase the content retrieved from the url
> because the content is read into buffer immediately (on the fopen call) and
> the filter isn't applied until the next line.
>
>$fp = fopen("http://www.php.net/";, "r");
>   /* the data is already sitting in buffer */
>   stream_filter_append($fp, "string.toupper");
>   while ($str = fgets($fp))
> print $str;
>   fclose($fp);
> ?>
>
>   Presumably you're aware of this?
>
> -Pollita
>
>
>
> --
> 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] Question on bug list

[Wez Furlong]

Hey,

Wouldn't it be nice/more useful to generate RDF/RSS on a per-bug basis?
Then you could just add the feed url to your favourite RSS client.

If you make it do that, then I will take a look and commit, provided
that there are no objections to this.

--Wez.

On Fri, 31 Jan 2003, Sara Golemon wrote:

> > I have a "daily page" I go to every morning which contains all my news
> > feeds, some comic strips, movie listings, etc If there were a
> > programmatic query interface to bugs.php.net I could select bug #s to
> track,
> > and be able to bring up histories of them from my daily page.
> >
> To that end... here's a simple script (based heavily on
> php-bugs-web/bug.php) to do just that:
>
> http://frankenbox.alphaweb.net/test/export.phps
>
> Meant to be called as:
>
> http://bugs.php.net/export.php?id=1234
>
>
> If it's deemed worthy could someone add it to php-bugs-web?  I don't have
> the karma.


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

[PHP-DEV] [PATCH] var_dump and friends dislike new style overload objects

[Wez Furlong]

The attached patch alters the var family of functions to be aware of the
get_class_name handler for overloaded objects.

It also checks that the object has a hash table for it's properties
before attempting to access it.

This patch is not 100% complete because it does not handle nested class
names.

I did not see a zend api function to do this, and IMO there should be
such a thing among the introspection functions in PHP 5.

Should I commit this patch?

--Wez.

Index: ext/standard/var.c
===
RCS file: /repository/php4/ext/standard/var.c,v
retrieving revision 1.155
diff -u -p -r1.155 var.c
--- ext/standard/var.c  18 Jan 2003 15:03:01 -  1.155
+++ ext/standard/var.c  30 Jan 2003 10:50:56 -
@@ -60,6 +60,8 @@ static int php_array_element_dump(zval *
 void php_var_dump(zval **struc, int level TSRMLS_DC)
 {
HashTable *myht = NULL;
+   char *class_name;
+   zend_uint class_name_len;
 
if (level > 1) {
php_printf("%*c", level - 1, ' ');
@@ -93,13 +95,18 @@ void php_var_dump(zval **struc, int leve
goto head_done;
case IS_OBJECT:
myht = Z_OBJPROP_PP(struc);
-   if (myht->nApplyCount > 1) {
+   if (myht && myht->nApplyCount > 1) {
PUTS("*RECURSION*\n");
return;
}
-   php_printf("%sobject(%s)(%d) {\n", COMMON, Z_OBJCE_PP(struc)->name, 
zend_hash_num_elements(myht));
+
+   Z_OBJ_HANDLER(**struc, get_class_name)(*struc, &class_name, 
+&class_name_len, 0 TSRMLS_CC);
+   
+   php_printf("%sobject(%s)(%d) {\n", COMMON, class_name, myht ? 
+zend_hash_num_elements(myht) : 0);
 head_done:
-   zend_hash_apply_with_arguments(myht, (apply_func_args_t) 
php_array_element_dump, 1, level);
+   if (myht) {
+   zend_hash_apply_with_arguments(myht, (apply_func_args_t) 
+php_array_element_dump, 1, level);
+   }
if (level > 1) {
php_printf("%*c", level-1, ' ');
}
@@ -166,6 +173,8 @@ static int zval_array_element_dump(zval 
 void php_debug_zval_dump(zval **struc, int level TSRMLS_DC)
 {
HashTable *myht = NULL;
+   char *class_name;
+   zend_uint class_name_len;
 
if (level > 1) {
php_printf("%*c", level - 1, ' ');
@@ -195,9 +204,12 @@ void php_debug_zval_dump(zval **struc, i
goto head_done;
case IS_OBJECT:
myht = Z_OBJPROP_PP(struc);
-   php_printf("%sobject(%s)(%d) refcount(%u){\n", COMMON, 
Z_OBJCE_PP(struc)->name, zend_hash_num_elements(myht), Z_REFCOUNT_PP(struc));
+   Z_OBJ_HANDLER(**struc, get_class_name)(*struc, &class_name, 
+&class_name_len, 0 TSRMLS_CC);
+   php_printf("%sobject(%s)(%d) refcount(%u){\n", COMMON, class_name, 
+myht ? zend_hash_num_elements(myht) : 0, Z_REFCOUNT_PP(struc));
 head_done:
-   zend_hash_apply_with_arguments(myht, (apply_func_args_t) 
zval_array_element_dump, 1, level);
+   if (myht) {
+   zend_hash_apply_with_arguments(myht, (apply_func_args_t) 
+zval_array_element_dump, 1, level);
+   }
if (level > 1) {
php_printf("%*c", level-1, ' ');
}
@@ -281,6 +293,8 @@ void php_var_export(zval **struc, int le
HashTable *myht;
char* tmp_str;
int   tmp_len;
+   char *class_name;
+   zend_uint class_name_len;
 
switch (Z_TYPE_PP(struc)) {
case IS_BOOL:
@@ -319,8 +333,11 @@ void php_var_export(zval **struc, int le
if (level > 1) {
php_printf("\n%*c", level - 1, ' ');
}
-   php_printf ("class %s {\n", Z_OBJCE_PP(struc)->name);
-   zend_hash_apply_with_arguments(myht, (apply_func_args_t) 
php_object_element_export, 1, level);
+   Z_OBJ_HANDLER(**struc, get_class_name)(*struc, &class_name, 
+&class_name_len, 0 TSRMLS_CC);
+   php_printf ("class %s {\n", class_name);
+   if (myht) {
+   zend_hash_apply_with_arguments(myht, (apply_func_args_t) 
+php_object_element_export, 1, level);
+   }
if (level > 1) {
php_printf("%*c", level - 1, ' ');
}

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

Re: [PHP-DEV] Compiling php4activescript

[Wez Furlong]

There are some additional libraries and tools that you need to be able to
build the win32 version.  The manual has more details here:
http://www.php.net/manual/en/install.windows.php

Please note that the ActiveScript SAPI is by no means ready for
production use (I would call it pre-alpha), and that it would be
particularly dangerous to deploy it for client-side scripting.
(PHP is just too powerful).

However, if you want to help iron out the bugs, go right ahead :)

--Wez.

On Mon, 27 Jan 2003, joe hansche wrote:

> I just tried downloading the latest stable source snapshot (
> http://snaps.php.net/php4-STABLE-200301271630.tar.gz at the time of
> posting ), and would like to compile the php4activescript library, and have
> been unsuccessful doing so.  Looking at the "Compile Log" on the snapshots
> site, when compiling the ZendTS project, the site's log shows this:
>
> =
> Configuration: ZendTS - Win32
> Release_TS_inline
> Performing Custom Build Step on ".\zend_language_parser.y"
> Performing Custom Build Step on .\zend_ini_parser.y
> zend_ini_parser.y:215.4-6: unrecognized escape: `\\0'
> Performing Custom Build Step on ".\zend_language_scanner.l"
> Performing Custom Build Step on .\zend_ini_scanner.l
> =
> But I am receiving this:
>
> =
> Configuration: ZendTS - Win32
> Release_TS_inline
> Performing Custom Build Step on ".\zend_language_parser.y"
> 'bison' is not recognized as an internal or external command,
> operable program or batch file.
> Error executing c:\winnt\system32\cmd.exe.
>
> php.exe - 1 error(s), 0 warning(s)
> =
> I don't see what I have done differently, but obviously I didn't do
> something right :\  I am opening the win32\php4ts.dsw workspace file, and
> building the Release_TS_inline configuration.  Is there anything else I need
> to configure in the project before it will compile?  Or is there something
> else I need to download?  All I really want to compile is the activescript
> library =[
>
> Thanks a lot,
> Joe Hansche
>
>
>
> --
> 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] php_stream size

[Wez Furlong]

At the moment, what you are currently doing is one of the simplest ways
of doing it portably, provided that the stream is seekable.

The other way is to call php_stream_stat() which returns the size,
ctime, mtime etc. of the stream, and can theoretically work on virtual
filesystems and wrappers (if those things implement the stat op, that
is!).  This is perhaps a better solution because the HTTP wrapper could
(but does not yet) provide the Content-Length information in the size
field of the stat structure (of course, the remote server might not send
a Content-Length header, so no size information would be present).

At the end of the day, the correct solution for your code depends on
what your code is trying to do; not all streams are seekable, so the stat
option is better, but then, stat is not guaranteed to return a sensible
size (or even any information).

If you are working on the stream in read-only operation, you can open
the stream using the STREAM_MUST_SEEK flag; this will cause the streams
layer to determine if the stream is seeekable; if it is not, it will
copy the stream into a temporary stream which is seekable. (The temp
stream is implemented as a memory buffer when the data are below a
certain threshold; when it gets too big for memory, it will
automatically use a temporary file for storage).
So you will be guaranteed that seek (and stat) will work on the stream,
but not guaranteed to be working with the actual resource you requested.
(Hence the reason that it is not suitable for read/write mode).

I hope that has helped!

--Wez.

On Sat, 25 Jan 2003, l0t3k wrote:

> wez,
> what's the most portable way to get the size of a stream ? right now im
> using
>
> stream = php_stream_open_wrapper ( path,  mode,  options, opened);
> php_stream_seek ( stream, SEEK_END, SEEK_CUR);
> size = php_stream_tell(stream);
>
> note that i have to also process the files, so i rewind immediately
> afterwards.
>
> for the moment, this is ok since im currently only using file-based streams.
> but i'd like to be able to be as generic as possible.
>
> l0t3k
> ps. would it make sense to have a get_size stream op ?


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

Re: [PHP-DEV] PHP 5.0.0-dev with J2sdk1.4.1_01 on Linux

[Wez Furlong]

Because it is now a part of the rpc extension, which currently does not
build under unix (but will do in the not too distant future).

--Wez.

On Thu, 23 Jan 2003, Seung Hwan Kang wrote:

> Is a Java extension removed or intensionally left over from PHP 5.0.0-dev?
>
> I have no error messge when I configured PHP 5.0.0-dev with a java extension
> (--with-java=/usr/java/j2sdk1.4.1_01) on linux machine (kernel 2.4.20-2).  I
> don't have any problem with make and make install too.  Only problem is that
> there is no java extension in PHP. phpinfo() does not tell me anything about
> Java on the screen.  Why?
>
>
>
> --
> 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] PHP4 + PHP5

[Wez Furlong]

On Tue, 14 Jan 2003, Mike Robinson wrote:
> I'm assuming PHP5 will use _only_ ZE2 once it's forked?

s/will/does/
s/once/now/




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

Re: [PHP-DEV] Re: [PHP-QA] Test results [failed] PHP5 (ZE2) on Tru64

[Wez Furlong]

Hi Magnus,

Please try changing file.c line 1485 so that it reads something like
this:

unsigned long len;
int type;

I would expect that to help reduce errors whenever the fscanf function
is called (used by the expectf section in tests?).

The other problem is within the url scanner in the trasn-sid thingy.
I'm not going to touch that code, as it is hairy enough, however, it
should just be a case of changing the declaration for the
scanner_output_handler function to be consistent with the other
functions that it calls.

--Wez.

On Mon, 13 Jan 2003, Magnus [ISO-8859-1] Määttãàwrote:

>
> Also, here are two possible problems.
>
> cc: Warning: /home/sas/src/php4/ext/standard/url_scanner_ex.re, line 415: In this 
>statement, the referenced type of the pointer value "handled_output_len" is "unsigned 
>int", which is not compatible with "unsigned long". (ptrmismatch)
> cc: Warning: /php/php4/ext/standard/file.c, line 1519: In this statement, the 
>referenced type of the pointer value "(&len)" is "int", which is not compatible with 
>"unsigned long". (ptrmismatch)
>
>
> / Magnus
>
> --
> 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: Stream filters, converters and i18n.

[Wez Furlong]

Derick has requested the ability to be able to specify an array
parameter instead of/as well as a string.
What I plan to implement is an additional (optional) filter operation
that is given an opportunity to pre-process the zval and make it
available to the underlying implementation.

> stream_filter_append($fp, "convert.quoted-printable-encode/base64-decode",
>   "base64-decode.ignore-eof=1,quoted-printable-encode.soft-line-break=1");

> stream_filter_append($fp, "convert",
>   "base64-encode:flush-on-close,forbid-seek/base64-decode:forbid-seek");
  ^^^
Streams API will spot a filtered stream and disallow seeking. (Except
for the emulated forward seek using read).

> Now what do you think of this? I need a decision.

The idea is that the filter name identifies a specific filter.
The parameters are used to tune specific aspects of the filter; such as
compression level, encryption keys and so-on.
So the former option is preferred...

As for the problem of choosing filters for the read/write streams, I
plan to introduce two separate read/write filter chains in PHP 5 and
allow the user to decide which filters to apply.

This needs to be comfortable for the user to pick and choose filters, so
it might require a modification to the user-space API, or perhaps the
introduction of a new function (latter is preferred).

> By the way, I find the converter is quite portable and also important
> for i18n stuff, I'd like to make the converter independent to
> the filter code. Any comments on this?

Having a core conversion system is a big plus (and will solve some of
the depenencies on mbstring issues we have for other extensions).

If the conversion system is abstracted nicely, it can provide a core set of
converters and allow other extensions (such as iconv, recode, mbstring)
to register other codesets (perhaps using a wildcard or some dynamic
query mechanism such as that used in the filters API) when they are
loaded at runtime.

If you do it this way, you get a +100 from me :-)

--Wez.


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

Re: [PHP-DEV] Terminal text objects (PHP CDK NCURSES)

[Wez Furlong]

This would be a nice thing to include in PECL (see http://pear.php.net).

--Wez.

On Wed, 8 Jan 2003, Nikolai Vladychevski wrote:

> Hello,
>
> I want to share the code (php-extension) I have included into php-4.2.2 to
> support CDK widgets
> (http://gd.tuwien.ac.at/hci/cdk/?file=cdk.tar.gz&type=listing) to enable PHP
> to use text based "GUI" in terminal environment.
>
> CDK supports:
>  -Alphalist (list with alphanumeric search)
>  -Calendar dialog box
>  -Dialog
>  -Entry field with type masking
>  -Scale field
>  -2 dimension graphics (text mode)
>  -Histogram display
>  -Item list field
>  -Label
>  -Marque (text box in movement)
>  -Matrix field
>  -Menu
>  -Scroll
>  -Selection field
>  -Slider field
>  -Radio button
>  -Template field


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

Re: [PHP-DEV] mailparse

[Wez Furlong]

We still haven't fully decided about how to document PECL extensions,
and there is talk of some kind of grand unified documentation system to
hold the PHP manual, PEAR/PECL manual and PHP Extension Authors manual.

However, everyone has precious little time for this, so things are
likely to stay as they are for a while.

At least you can read the docs ATM :)

--Wez.

On Wed, 8 Jan 2003, Morten Winther wrote:

> Hello,
>
> When you look up mailparse on php.net it doesn't say that this function is
> moved PEAR.
>
> Shouldn't this be corrected?
>
> http://www.php.net/manual/en/ref.mailparse.php
>
> --
> / morten
>
> "There are only 10 types of people in the world: Those who understand
> binary, and those who don't"
>
>
>
> --
> 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: [PHP-CVS] cvs: php4 /ext/standard filters.c

[Wez Furlong]

With the current model, the concept is that you can use either the
filter name or filter parameters to distinguish the ultimate behaviour.

Yes this is a possible headache.
I am thinking that two separate chains of filters (one for reading and
one for writing) might make this situation a little easier;
this way you could have a filtered read stream but leave writing
unfiltered etc.

--Wez.

On Wed, 8 Jan 2003, Moriyoshi Koizumi wrote:

> Hi,
>
> On Tue, Jan 07, 2003 at 12:12:15PM -0800, Sara Golemon wrote:
> > Speaking of filter "string.base64" I have an issue with its parity.
> >
> > string.base64 will encode on write and decode on read... What if the user
> > wants the other way round?  Is the expected behavior even obvious from the
> > name alone?  Should there be two separate filters? string.base64-encode &
> > string.base64-decode with each doing the same opperation on either read or
> > write?
>
> Agreed. I hit the same problem you mentioned while implementing iconv
> encoding conversion filter. I should have made the filters capable of
> working in the opposite way.
>
> But would it rather be preferred to switch the filter function by
> parameters given to the factory, than to have two similar filters?
>
> Then the problem is there's no unified way to handle those parameters.
> Actually it will do for me to make my own handler, but I see it will
> definitely end up in great inconsistency.
>
> 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] stream filter problem

[Wez Furlong]

the filter write functions should return the number of bytes of
the input buffer that they *consumed*, not how many were written.
(The read function should of course return the number read, but cannot
exceed the maximum buffer size).

However, there also seems to be a similar sounding problem with the
user-space filters; I will investiage in more detail later this weekend,
if I get time.

--Wez.

On Sun, 5 Jan 2003 [EMAIL PROTECTED] wrote:

> Hi,
>
> I'm currently working on base64 filter, and then I'm stuck with odd
> behaviour of stream_filter_write op. When I try to write some larger
> chunk to the next output filter than the length of buffer passed to
> my function, stream segfaults sometimes or goes into infinite loops on
> other attempts in the next call of the write op.
>
> Is this just my fault that I should always limit chunk length within the range
> of the given length? Or possible stream bugs?
>
> Please try the attached patch and run the following script to reproduce the
> problem.
>
>  stream_filter_append(STDOUT, "string.segfaulting");
> fwrite(STDOUT, "test");
> ?>
>
> Thanks,
>
> Moriyoshi
>


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

Re: [PHP-DEV] 4.3.0, RedHat 7.3:"Fatal error: Nesting level too deep- recursive dependency? in Unknown on line 0", even with empty file

[Wez Furlong]

Make a backtrace and then we will have a clue about what is happening...

--Wez.

On Thu, 2 Jan 2003, Tobias Schlitt wrote:

> Hi everyone!
>
> Today i compiled 4.3.0 on my Laptop (Redhat 7.3). Compiling
> works fine. Running Scripts works (until now) fine. Except,
> that i'm getting the same error, with every file i parse (even
> with whole empty ones).
>
> The Error is: "Fatal error: Nesting level too deep - recursive
> dependency? in Unknown on line 0".
>
> I have no auto_prepend oder _append settings defined inside my
> php.ini. The error occurs with the apache SAPI and with the
> CLI, too.
>
> Does anyone know about this error or / and know how to fix
> that? Or may it be a bug??


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

Re: [PHP-DEV] Patch for #21330 - socket_select()

[Wez Furlong]

It's also broken as it will not allow for a null value to give an
infinite wait period.

--Wez.

On Thu, 2 Jan 2003, Tularis wrote:


> if (sec != NULL || sec != 0) {
> convert_to_long_ex(&sec);
> tv.tv_sec = Z_LVAL_P(sec);
> tv.tv_usec = usec;
> } else {
> tv.tv_sec = 0;
> tv.tv_usec = 0;
> }
> tv_p = &tv;
>
> But, as I said it's just a fashion statement, and nothing important...
> let stand that it will make *any* difference ;)
>
>
> --
> 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: Patch for #21330 - socket_select()

[Wez Furlong]

#21330 actually sounds completely bogus after having looked at the
code...

--Wez.

PS: add "diff -u" to your .cvsrc

On Thu, 2 Jan 2003 [EMAIL PROTECTED] wrote:

> This is the patch that fix the issue of socket_select that doesn't wait if
> value for timeval is 0.
>
> Tell me what you think.
>
> Regards.
> M.CHAILLAN Nicolas
> [EMAIL PROTECTED]
> www.WorldAKT.com Hébergement de sites internets.
>
>



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

[PHP-DEV] ChangeLog

[Wez Furlong]

Is there some magic that needs to be done to rotate the ChangeLog?
By this I mean:

gzip ChangeLog
mv ChangeLog.gz ChangeLog2002.gz
touch ChangeLog
cvs add -kb ChangeLog2002.gz
cvs ci -m "rotate changelog" ChangeLog ChangeLog2002.gz

It seems the most recent entry in the log is from the 29th December, and
I wonder if some script needs to be kicked to update the log.

--Wez.


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

[PHP-DEV] CVS mangled (netware/apachecore.imp, netware/bisonflexzend.bat)

[Wez Furlong]

% cvs -q up
cvs server: nothing known about netware/apachecore.imp
cvs server: nothing known about netware/bisonflexzend.bat

I can't find any trace of these files in my checkout (or in the CVS
files), so I presume that something has been munched on the server
side?

--Wez.


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

[PHP-DEV] PHP in 2003 (leading to PHP 5)

[Wez Furlong]

I hope you all had a joyous night last night and that it forms that
start of a great New Year!

Now, let's get our heads straight on what we are doing for 2003 :)

You may remember (especially if you read Derick's Look Back) that I said
something about building against ZE2 by default once we released PHP
4.3 [1].  I still think this is a good idea because it will force us to make
sure that things are working properly - those extensions that implement
classes and manipulate objects need the most attention.

Once we have stabilized the combination of 4.4 + ZE2, are there any
other *realistic* goals for PHP 5 to fit into slot no. 4 below?

Are there any reasons not to switch to ZE2 right away?

--Wez.

Roadmap:

1.  Switch to ZE2 by default
2.  Establish PECL CA authority and binary package/release process
(particularly important for win32)
3.  Bundle PHP-Soap (and stop the "bleeding of PHP users")
3a. Collect underpants
4.  ?
5.  Profit

 [1] http://news.php.net/article.php?group=php.dev&article=87097


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

Re: [PHP-DEV] Re: #21139 [Ctl]: zlib.output_compression + windowsfailure

[Wez Furlong]

This sounds like the same kind of problems we've encountered with PCRE
mbstring and openSSL extensions on windows and their use from other modules.

Isn't the solution as "simple" as changing the #ifdef to include
COMPILE_DL_ZLIB in the checks, or is this another situation where the
zlib extension should be compiled into the distribution itself?

Is there a problem with doing that in the win32 build Edin?
(it seems that the unix build will also have the same problems if zlib
is built as a shared extension - there was even a bug report today about
related issues).

On Mon, 23 Dec 2002, Moriyoshi Koizumi wrote:

> Therefore I think the modified part should be reverted for now, unless
> there is a better way to fulfill the requirement (see bug #16109).

Let's see what the other "output guys" have to say on this matter.

> BTW since when did I become a "output guy" ? :)

Since you began to follow-up on this report ;-)

--Wez.


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

[PHP-DEV] Re: #21139 [Ctl]: zlib.output_compression + windows failure

[Wez Furlong]

This needs one of you "output guys" to resolve it.
Andrei mentioned something about making the final release before 1st
Jan, so if you can, please get your coding-butts in gear :)

--Wez.

On 22 Dec 2002 [EMAIL PROTECTED] wrote:

>  ID:   21139
>  Updated by:   [EMAIL PROTECTED]
>  Reported By:  [EMAIL PROTECTED]
>  Status:   Critical
>  Bug Type: Output Control
>  Operating System: Windows
>  PHP Version:  4.3.0RC4
>  New Comment:
>
> Verified on Windows, with Apache or Apache2.
>
> -- HTTP response dump of the following script --
>
> 
>
> -- Apache_1.3.27 --
> HTTP/1.1 200 OK
> Date: Sun, 22 Dec 2002 18:06:53 GMT
> Server: Apache/1.3.27 (Win32) PHP/4.4.0-dev
> X-Powered-By: PHP/4.4.0-dev
> Connection: close
> Content-Type: text/html
>
> (correctly gzip-encoded content)
>
> -- Apache_2.0.43 --
> HTTP/1.1 200 OK
> Date: Sun, 22 Dec 2002 18:06:15 GMT
> Server: Apache/2.0.43 (Win32) PHP/4.4.0-dev
> Last-Modified: Sun, 22 Dec 2002 17:59:26 GMT
> ETag: "45a2-1b-e744bab1"
> Accept-Ranges: bytes
> Content-Length: 27
> Connection: close
> Content-Type: application/x-httpd-php
>
> 
> Warning:  (null)() [ href='http://www.php.net/ref.outcontrol'>ref.outcontrol]: Cannot
> change zlib.output_compression - headers already sent in Unknown
> on line 0
> abcde
>
>
> Previous Comments:
> 
>
> [2002-12-21 19:27:53] [EMAIL PROTECTED]
>
> I can confirm this bug on Windows + Apache + zlib.output_compression in
> .htaccess.
>
> If zlib.output_compression is set to on from php.ini it works. It only
> doesn't work if set from .htaccess.
>
> 
>
> [2002-12-21 17:48:30] [EMAIL PROTECTED]
>
> I have just installed latest php 4.3 on linux and windows.
> I use the same directory and therefore .htaccess files for
> apache/mod_php on both platforms.
>
> When i enable enable output compression with ini setting
> php_value zlib.output_compression On
> in .htaccess the linux version works as expected but the
> windows version fails. Sometimes i receive errors with
> access violations. Sometimes i can downlowd the result
> but when rename the resulting file to .gz i can open it and
> as you might expect it contains the correct result. And
> sometime i see the encoding result presented in the browser
> and then i cannot save and view it although the gzip header
> seems correct.
>
> marcus
>
> 
>
>
> --
> Edit this bug report at http://bugs.php.net/?id=21139&edit=1
>
>
>


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

Re: [PHP-DEV] CGI and CLI (compromise proposal)

[Wez Furlong]

If my vote has enough "Karma Power", then I'm +1 for this solution.

--Wez.

On Thu, 19 Dec 2002, Edin Kadribasic wrote:

> After having consulted with Andrei, Derick and others on irc here is
> a proposal for a compromise:
>
> On Unix:
>
> 1. Both cgi and cli are built as 'php' in their respective sapi
> directories (pretty much as it is today except that cgi gets renamed
> back from php-cgi to just php).
> 2. Make install will *not* install cli if cgi build was selected
> (only cgi gets installed).
> 3. A new install target 'install-cli' is introduced so that make
> install-cli will overwrite whatever is in $(PREFIX)/bin/php.
>
> On Windows:
>
> 1. php.exe in the root of distribution is php cgi sapi.
> 2. New cli directory is included with php.exe (cli) in it.
>
> If this is an acceptable compromise I volunteer to do the changes
> required.


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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /sapi/cli php_cli.c

[Wez Furlong]

On Thu, 19 Dec 2002, Wez Furlong wrote:

> Actually, it does seem valid to me; streams based on FILE* are not
> registered in the persistent list, so does it make sense to have the
> associated resources registered as persistent resources when they will
^^^
constants

> get cleaned up by the engine at request shutdown?
>
> --Wez.
>
> On Wed, 18 Dec 2002, Andi Gutmans wrote:
>
> > I don't like these voodoo patches. I think if the stream is destroyed twice
> > that should be solved and not the constant itself.
> > Unless you have a good reason please revert your patch and talk to Wez
> > about fixing this properly.
> > Thanks,
> >
> > Andi
>
> -   ic.flags = CONST_CS | CONST_PERSISTENT;
> +   ic.flags = CONST_CS;
>
>
>
> --
> 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] Re: [PHP-CVS] cvs: php4 /sapi/cli php_cli.c

[Wez Furlong]

Actually, it does seem valid to me; streams based on FILE* are not
registered in the persistent list, so does it make sense to have the
associated resources registered as persistent resources when they will
get cleaned up by the engine at request shutdown?

--Wez.

On Wed, 18 Dec 2002, Andi Gutmans wrote:

> I don't like these voodoo patches. I think if the stream is destroyed twice
> that should be solved and not the constant itself.
> Unless you have a good reason please revert your patch and talk to Wez
> about fixing this properly.
> Thanks,
>
> Andi

-   ic.flags = CONST_CS | CONST_PERSISTENT;
+   ic.flags = CONST_CS;



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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /sapi/cli php_cli.c

[Wez Furlong]

Would this solve the problem?

Index: main/main.c
===
RCS file: /repository/php4/main/main.c,v
retrieving revision 1.520
diff -u -r1.520 main.c
--- main/main.c 16 Dec 2002 15:43:52 -  1.520
+++ main/main.c 19 Dec 2002 13:06:45 -
@@ -1337,9 +1337,9 @@
php_shutdown_ticks(TSRMLS_C);
sapi_flush(TSRMLS_C);

+   php_shutdown_stream_wrappers(module_number TSRMLS_CC);
zend_shutdown(TSRMLS_C);

-   php_shutdown_stream_wrappers(module_number TSRMLS_CC);

php_shutdown_info_logos();
UNREGISTER_INI_ENTRIES();


On Thu, 19 Dec 2002, Edin Kadribasic wrote:

> > >Sorry, I'm still unsure if my patch is the correct one, as I said in the
> > >first mail. As far as I've looked into it, the streams seem to be
> > >destructed and freed twice, once in deactivation and once in shutdown.
> > >If you think my patch is bogus, feel free to revert it unless I can give
> > >more reasonable explanation.
>
> I comitted tha patch and I'll revert it. Just to clarify one thing:
> constanst throuout PHP should be created as CONST_PERSISTENT?
>
> Edin
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>

Index: main/main.c
===
RCS file: /repository/php4/main/main.c,v
retrieving revision 1.520
diff -u -r1.520 main.c
--- main/main.c 16 Dec 2002 15:43:52 -  1.520
+++ main/main.c 19 Dec 2002 13:07:04 -
@@ -1337,9 +1337,9 @@
php_shutdown_ticks(TSRMLS_C);
sapi_flush(TSRMLS_C);
 
+   php_shutdown_stream_wrappers(module_number TSRMLS_CC);
zend_shutdown(TSRMLS_C);
 
-   php_shutdown_stream_wrappers(module_number TSRMLS_CC);
 
php_shutdown_info_logos();
UNREGISTER_INI_ENTRIES();

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

Re: [PHP-DEV] Re: output buffering problem

[Wez Furlong]

Please ask these questions on the php-general list.

--Wez.

On Thu, 19 Dec 2002, electroteque wrote:

> sorry about the false alarm , if you go here u will see a working example
>
> http://galleries.dyndns.org:1023/progress.php
>
> i had to add both flush functions together to work , obviosuly flsuh is not
> emptying the buffer within a loop, is this still a bug ?
>
> flush();
>  ob_flush();
> "Electroteque" <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > hi guys i have the latest cvs , my function used to work now it doesnt
> >
> > function
> > progressbar_percentage($i,$files,$newwin,$moviename,$status,$sleep=null){
> >  if (is_array($files)) $per = $i/count($files); else $per = $i/$files;
> >  $per = $per*100;
> >  $buffer = "\n";
> >  $buffer .= "var movie=".$newwin.".document.".$moviename.";\n";
> >  $buffer .= "movie.TGotoFrame(\"_root.Status\", 1);\n";
> >  $buffer .= "movie.SetVariable(\"_root.Status.processing\",
> > \"".$status."\");\n";
> >  $buffer .= "movie.TSetProperty(\"_root.Bar\",2, ".ceil($per).");\n";
> >  $buffer .= "movie.SetVariable(\"_root.Percent.per\", \"".ceil($per)."
> > %\");\n";
> >  $buffer .= "\n";
> >  print ($buffer);
> >  flush();
> >  sleep(1);
> > }
> >
> > this i meant to flush on every loop and show a progress percentage
> although
> > now php wont flush anything until half way through the loop and causes
> > javascript errors as it never flushed until too late , what could be the
> > problem ?
> >
> >
>
>
>
> --
> 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] php.exe - php-cgi.exe

[Wez Furlong]

[imagine large quantities of quoted text here]

On Wed, 11 Dec 2002, Edin Kadribasic wrote:
> > So i am -1 on renaming CLI
> > And +1 on keeing CGI as php-cgi and CLI as php
> > marcus
> Just for the record: my vote is the same.

me too

[imagine large quantities of quoted text here]


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

Re: [PHP-DEV] 4.3 when?

[Wez Furlong]

I have a patch from Melvyn for streams under *BSD systems, and the
critical bugs should also be fixed, particularly 20539, 19919 and 19292.

[15209] Under Apache, register_shutdown_function() broke between 4.0.x to 4.1.x
[19292] random error: open_basedir restriction in effect. File is in wrong directory
[19919] segmentation violation in sapi_apache_header_handler, mod_php4.c  line 208
[20109] iplanet 6 core dump w/NSAPI load
[20190] Random mem corruption: zend_get_executed_filename() mismatch
[20467] Buffer overflow returning binary (sybase)
[20539] PHP CLI Segmentation Fault
[20802] memory limit crash

--Wez.

On Mon, 9 Dec 2002, Andi Gutmans wrote:

> Any idea how many more bugs are waiting to be addressed?
>
> Andi
>
> At 12:36 PM 12/9/2002 +0000, Wez Furlong wrote:
> >Because we are still finding and fixing bugs in the RCs.
> >
> >--Wez.
> >
> >On Mon, 9 Dec 2002, Andi Gutmans wrote:
> >
> > > Now that still leave my original question about 4.3. Why the hell aren't we
> > > rolling it?
> >
> >
> >
> >--
> >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] 4.3 when?

[Wez Furlong]

Because we are still finding and fixing bugs in the RCs.

--Wez.

On Mon, 9 Dec 2002, Andi Gutmans wrote:

> Now that still leave my original question about 4.3. Why the hell aren't we
> rolling it?



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

RE: [PHP-DEV] php.exe - php-cgi.exe

[Wez Furlong]

On Sun, 8 Dec 2002, Mike Robinson wrote:
> Every system on the planet that uses php.exe as their CGI executable,
> and I suggest there are quite a few, will have a broken setup with a
> stock install of php-4.3.0, because typing php-cli.exe at the command
> line is too long. And you expect putting huge notes and warnings in the
> news file and installer will prevent this from happening.

Any sysadmin upgrading to a new release should read the release notes,
or be fired. (It's quite simple)

There are a number of things to review before upgrading to PHP 4.3.
One of the big things to note is that the CGI version of PHP has not
been functioning correctly for some time now (see Shane's recent
thread), and that 4.3 will finally correct this issue.

> > The reason against renaming CGI and using its old name for
> > the CLI now would have lead us to register_globals=ON for eternity.
>
> Totally different. Apples and oranges.
> That was a security-related change, and IMHO, the amount of trouble
> _that_ change caused far outweighed the meagre benefits achieved.

It's called progress.  We try to retain BC as much as possible and as
much as makes sense, but sometimes we have to make some progress.
That's what we are doing here.

In case you haven't noticed, a lot of work is being done to elevate PHP
beyond the status of a web-only language; this is a positive step in
that direction.

> This change is going to break a lot of setups for the sake of cli users
> saving a few keystrokes.

CGI was broken anyhow - this is going to *fix* a lot of setups,
regardless of "saving a few keystrokes".

> Sorry. There's just no way this should happen.

But it has happened, and it's going stay this way.

Now, if you don't have anything positive to contribute, please stop
stirring up threads like this (again) without first understanding the
issues behind them.  It just wastes time, which is better spent
developing, bug fixing, documenting - doing just about anything else is
more productive.

--Wez.


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

Re: [PHP-DEV] OpenSSL wrappers for PHP 4

[Wez Furlong]

Sounds great, and sounds like it should be part of ext/openssl and it's
up-coming stream implementation (most of the code is in main/network.c
ATM).

I'd really appreciate your input on making most of your work use the new
streams architecture. (which really means that most of those calls will
go away and be replaced with "generic" stream calls and context
settings).

I want to create a "stream server" API for hosting sockets etc. using
the familar fread(), fwrite() family of functions, which will
incorporate aspects of ext/sockets and add optional openssl support
(which can be toggled at runtime for things such as "starttls" based
protocols).

If you're not interested in streams at this time, I'd be "-0" on adding
your extension to our CVS, meaning that I think the functionality should
be rolled into the existing client-side SSL we have in streams, rather
than creating a load of new functions, so I would feel a resistance to
adding all those new functions, but don't have a problem with it
going in if there is sufficient demand.

--Wez.
"The Streams Guy"
and openssl extension maintainer

On Mon, 2 Dec 2002, David Gillies wrote:

> Hi,
>
> I'm new to this list...
>
> Over the past few weeks I've been working on a PHP4
> module, called securesocket, that wraps several of the
> OpenSSL routines. So far, there's about 75 routines in
> my module, covering essentially all of the basic
> routines required to perform SSL connections (support
> for client-oriented routines is slightly more advanced
> than for servers). At present there is support for
> connecting to a server, verifying certificates
> (partially), reading, writing, buffered BIOs and
> getting/setting SSL operating modes.
>
> My module is starting to get to the point where it is
> mature enough for me to consider releasing it
> (although it's still in a very rudimentary form). Is
> anyone interested in having a look at what I've done?
>
> At present I don't have access to my own
> publicly-accessible server. If anyone is interested in
> helping me host this, ideally as part of a
> collaborative effort using CVS, then please contact
> me.
>
> Best Wishes,
>
> David Gillies
> San Jose
> Costa Rica
>
>
> P.S.
> A minimal SSL session with my module might look
> something like the following:
>
> $ctx=securesocket_ssl_ctx_new(securesocket_sslv3_client_method());
> $ssl=securesocket_ssl_new($ctx);
>
> $sock=securesocket_connect_to_host("localhost",443);
> securesocket_ssl_set_fd($ssl,$sock,BIO_NOCLOSE);
> securesocket_ssl_connect($ssl);
>
> $peer=securesocket_ssl_get_peer_certificate($ssl);
>
> $getstr="GET / HTTP/1.0\r\n\r\n";
> securesocket_ssl_write($ssl,$getstr,strlen($getstr));
> $bytes=securesocket_ssl_read($ssl,&$repstr,1024);
>
> securesocket_ssl_shutdown($ssl);
> securesocket_ssl_free($ssl);
> securesocket_ssl_ctx_free($ctx);
>
>
> __
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.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

[PHP-DEV] Re: Modules/Extensions not in 4.3

[Wez Furlong]

Hi Philip,

On Fri, 29 Nov 2002, Philip Olson wrote:

> So "mainstream" is defined as which are bundled with the
> PHP4 source, whether it's in PECL or not?  Does anyone
> know or have a list of what will go where and when? Is
> the install, configure, and use process different for
> PECL extensions?  Why are any PECL extensions bundled in
> PHP4 source?  That seems to defeat the purpose.

As I just explained to you on IRC (and repeating here "for the record"),
the aim is to have a virtually empty php5/ext/ directory and have all
extensions (besides standard) living in PECL.
Once in PECL, the extensions gain dependency tracking information.

When we publish a release, we will pick the "gold" extensions based on
the userbase (popular extensions will be included by default) and the
level of maintenance (crufty extensions might not be bundled by
default).

> > So, what I'd like to see (and this seems reasonable, IMO) is:
> >
> > o One doc download for the PHP core + bundled extensions (which may
> > reside in PECL).
> > o One doc download for the PEAR classes + non-bundled PECL extensions
> > o One doc download for extension developers (the streams and zend API
> > stuff needs a proper home).
> > o One doc system to rule them all (but keep it modular of course).
>
> Regarding the separate developers manual, the main reason it
> hasn't already been done (aside from time constraints) is there
> is question on whether it should be translated or not.  I vote no
> it shouldn't as that'd mean outdated developer docs as the zendapi
> stuff seems to change a lot and translations are slow and
> sometimes are just one-time operations.  In fact, aren't the current
> en zendapi docs already outdated?  I don't know this topic.  On a
> related note, those PHP4/README.* docs would  fit nicely in this
> dev manual.

Yes, the developer docs should be written only in english for the
reasons you mention above (which are similar to the reasons for not
localizing the php error messages).

--Wez.


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

Re: [PHP-DEV] Bug #20308 (Feature Request)

[Wez Furlong]

On Fri, 29 Nov 2002, Sara Golemon wrote:

> I'm not so much worried about the user in this case, a few explodes will
> keep them happy.  I'm more worried about the behavior of parse_url being
> just plain lacking.   mailto:[EMAIL PROTECTED]?subject=Bug+20308 should be
> entitled to everybit as much parsing as
> http://joe:[EMAIL PROTECTED]/pathto/somepage?var=value
>
> The ONLY real concern here, and reason for not fixing php_url_parse, comes
> in the fact that 'path' would no longer contain
> '[EMAIL PROTECTED]?subject=Bug+20308' (per the example above) which would
> likely break existing scripts.

Because mailto URL is not one of the common internet/host URLs (that
parse_url was designed to handle), this should not happen.

> Perhaps the compromise is to create a new function 'parse_url_rfc' (name
> could be better) which behaves correctly (without having special cases).
> Then add a note to the manpage for parse_url saying to use parse_url_rfc
> instead, and eventually depricate parse_url (perhaps with PHP 5.0).

But which RFC would it follow? There are at least 3 :)

Why not just use the Net_URL pear package?

--Wez.


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

Re: [PHP-DEV] Re: Modules/Extensions not in 4.3

[Wez Furlong]

IMO, the manual should include all of the "maintstream" PHP extensions.
The reasoning is that if someone downloads the PHP manual, they expect
to get the PHP manual and not have to hunt around for docs on extensions
X, Y, Z.

Remember that one of our goals is to move most of ext/* into PECL, but
still bundle these pickled extensions in our official release packages,
so the idea that PECL should be documented under PEAR is not such a good
one.

Again, IMO, the madness of having no less than 3 different docu systems
(phpdoc, peardoc and peardoc2) makes very little sense; why not just use
"one system (tm)" for docs? (let's save some developer brain power for
more useful things).

So, what I'd like to see (and this seems reasonable, IMO) is:

o One doc download for the PHP core + bundled extensions (which may
reside in PECL).
o One doc download for the PEAR classes + non-bundled PECL extensions
o One doc download for extension developers (the streams and zend API
stuff needs a proper home).
o One doc system to rule them all (but keep it modular of course).

--Wez.

On Fri, 29 Nov 2002, Philip Olson wrote:

> > >> The peardoc format will be phased out for peardoc2 which
> > >> uses several files, that is one per function, one for constants,
> > >> etc.
> > >>
> > >> It makes sense to document PECL in the pear manual since PECL is
> > >> in pear.
> > >
> > > Well, actually this what I wanted to hear :) I also think that moving
> > > PECL module's manuals to PECL is the way to go. Those extensions are
> > > mostly rarely used... We can make up a list in the manual about moved
> > > extensions and some text about why this happened / happens...
> >
> > IMO, a lot of extensions that are currently documented in the PHP
> > manual could be moved to PECL and PEAR doc. This would make the
> > PHP manual lighter to download, display, handle. The PHP manual
> > could keep documentation about the core extensions (still to be
> > defined).
>
> This isn't really the question as we (the doc teams) don't make
> these (php4/ext->pecl) decisions.  I don't think anyone feels
> the documentation of PECL modules belong in the php manual or
> vice versa but the question is how and when to deal with the
> moved extensions.  When the php-dev team moves an extension we:
>
>   (a) Move the docs (phpdoc->peardoc)
>
>   Verify the docs are online in the pear manual before removed
>   from the php manual. (which means the peardoc vs peardoc2
>   craziness must also be dealt with)
>
>   (b) Make sure php.net/{extensionname} still does something
>   useful.
>
>   Whether filler pages or 404 handles this is in question.
>   And whether or not individual functions are kept track
>   of is another.  Also, this may just refer to (c).
>
>   (c) Make a note in an up-and-coming phpdoc appendix page on
>   moved and removed extensions which may look like:
>
>   =
>   | Extension | Change | Reason   | Moved in  |
>   =
>aspell   removed  pspell..   4.3.0
>cybercashremoved  ...4.3.0
>cybermut moved..  ...4.3.0
>   -
>
>   (d) ???
>
> Ideally the php-dev team can provide a timeline for (some) future
> moves and/or discuss each extension in detail and make a decision.
> Maybe all moves have been completed?.  For now, we rely on NEWS
> entries.
>
> Most of the above applies to removed extensions too except they
> won't go into peardoc but rather remain in phpdoc for an
> undisclosed (a long) amount of time.  A few were removed in 4.3.0,
> see NEWS and CVS entries for details.  Removed/deprecated
> extensions have been dealt with in a couple different ways:
>
>   (1) icap   : php.net/icap simply redirects to php.net/mcal
>icap docs are not generated.
>   (2) aspell : All deprecated functions have been listed for
>quite some time.  It also mentions "use pspell"
>   (3) Redirect to (c) above.
>
> I prefer the second because of historical reasons and the
> fact that users may still be using the old functions.  For
> how long will these docs remain?  Should they ever go in the
> appendix instead?  Will this confuse users?  These are good
> questions :)  Also, what is done may depend on the individual
> extensions themselves although consistancy has its merits.
>
> Regards,
> Philip Olson
>
>
> --
> 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] PHP 5 - when?

[Wez Furlong]

Hi Piotr,

The short answer is that it will be ready when it is ready :)

We don't have a definite time frame for PHP 5 (we are not 100% sure what
features it will contain), and probably won't have a definite time frame
until we begin the release cycle (typically a month or more before we
release the code).

At the moment we are doing QA on the PHP 4.3 release, with RC2 due this
week.  If you want a better idea of the ETA of 4.3, Andrei should have
the answers (he is coordinating this release).

The best way to stay up to date is to monitor this list; if you are
short on time, you can find a weekly summary of this list on zend.com
(in the developer zone).

Hope that helps,

--Wez.

On 27 Nov 2002, Piotr Sobolewski wrote:

> Hi,
>
> First of all - I hope I post to the right group. I could not find
> any righter group for my question
>
> Can somebody tell me when the version 5 of PHP will be released?
> Can I find such plans at some website? Like:
> "We plan to release version 4.3 in march, and then the version 5
> about may"
> ?
>
> I ask about it because I am not always up-to-date with PHP development.
> I am an editor of a polish software magazine, and I plan to make an
> issue dedicated to PHP_5 when it is released.
>
> Thanks for information - in advance
>
> --
> Pozdrawiam,
> Piotr Sobolewski, wydawnictwo Software
> [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] Concrete suggestion re: i18n messages

[Wez Furlong]

If I wanted localized error messages, then this would be the way to do
it.  Perhaps merging this with the php_error_docref might be slightly
better.

However, I'm personally -1000 on such things; there are many reasons,
most of them have already been raised here, so I won't repeat them now,
but the main issue is with the maintainability of such a thing;
localization is very hard to maintain on a volunteer basis (just look at
our manual).

For something as important as error messages, it is better to have the
"definitive" error message in english and then take advantage of the
hyperlink generated by php_error_docref which will display more detailed
information in the localized manual.

--Wez.

On Tue, 26 Nov 2002, Sascha Schumann wrote:

> A possible implementation would look like this:
>
> A new ini setting is added.
>
> php.error_lang
>
> A new function is provided.
>
> php_error_ex(int type, const char *err_code, const char *fmt, ...);
>
> The function tries to lookup the  key in
> php-.cat.  If it exists, the value will be
> used instead of the format .  The control is then passed
> to php_verror().
>
> That sounds like 30-50 additional LOC to me.  No bloat in
> sight.
>
> The program which generates the .cat files (gen-cat) will
> ensure that the error code is prepended to the format
> message.  That could be a simple C file with another 50 LOC,
> parsing input files of the form
>
> file: file line | line
> line: ERROR-CODE MSG
>
> Each extension can maintain its own file (e.g. cat.session.nl for
> the NL version of the session error messages).  During
> .cat build-time, a single per-language file is generated and
> fed through gen-cat.  The result can then be used by PHP.
>
> There, simple and straight-forward.
>
> - 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 4.3.0] Win32 CoInitalize/CoUninitialize CallMove

[Wez Furlong]

+1

Makes very much sense (almost too much sense!) to me.

--Wez.

On Mon, 25 Nov 2002, Michael Sisolak wrote:

> While stess testing the recent threading fixes under the ISAPI module I
> was seeing a lot of instability in IIS after the testing finished.
> While the PHP pages would continue to load, no ASP pages would anymore.
>  I have tracked this down to the placement of the Win32 CoInitialize()
> and CoUninitialize() calls.  In the current 4.3.0 release candidate
> CoInitialize() and CoUninitialize() are only called once per thread
> (from the basic_globals_ctor/_dtor in basic_functions.c).  According to
> Microsoft, however, at
> http://msdn.microsoft.com/library/en-us/iisref/html/psdk/asp/devs0hm5.asp:
>
> "COM initialization, from CoInitialize or CoInitializeEx, affects the
> thread in which it's called. For this reason, you cannot initialize COM
> unless you uninitialize it before returning from your callback
> function. [ . . .] CoInitialize and CoUninitialize need to be called in
> order. If one is called twice in a row, by different ISAPIs on the same
> thread, your users may see error 270."
>
> This is exactly the error I am seeing: if I load an ASP page in a
> thread that has processed PHP pages I get the 270 error (reported as
> "Error -2147417842 (0x8001010e)").  I moved the CoInitilize call to
> PHP_RINIT_FUNCTION(basic) and CoUninitialize to
> PHP_RSHUTDOWN_FUNCTION(basic) and reran my stress testing.  After
> 100,000 PHP page loads IIS now remains stable and able to process both
> ASP and PHP pages.
>
> I ran this by Zeev and he suggested that some kind of just-in-time COM
> initialization, but I'm not going to have the time to get to this full
> solution until later.  In the meantime for 4.3.0 I request that the
> attached patch is applied that moves the CoInitialize or CoInitializeEx
> calls to be per-request.  This is the last little fix that all the
> multi-threading bug fixing to make the ISAPI rock solid in 4.3.0
> requires.  I've done a lot of testing and feel very confident about
> including this patch.
>
> Michael Sisolak
> [EMAIL PROTECTED]
>
>
> __
> Do you Yahoo!?
> Yahoo! Mail Plus •àPowerful. Affordable. Sign up now.
> http://mailplus.yahoo.com


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

Re: [PHP-DEV] Mailparse extension

[Wez Furlong]

Hi Mike,

I'm ironing out a few nasty bugs; I'm aiming to have it stable either in
time for 4.3 or very shortly afterwards.

(It's not bundled with the core any longer - it's now in PECL)

--Wez.

On Tue, 19 Nov 2002, Mike Hall wrote:

> Is this going to be production stable in 4.3.0?
>
> Cheers,
>
> Mike
>
> --
> 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] ZE2 and classes

[Wez Furlong]

php.net/get_defined_functions and
php.net/get_class_methods not good enough for you? ;-)

What's the long term aim?

--Wez.

On Tue, 19 Nov 2002, Marcus [iso-8859-1] Börger wrote:

> I have experimented with the code below.
>
> The main thing is to introduce a function that can return a list of
> all available functions (this is a first step to something bigger...).
>
> At this point i have three problems:
> 1) When i create a function it is shown in the result :-)
> 2) When i create a class it is shown twice (same goes with methods) :-(
> 3) When i look for internal classes there is the problem that the the
> function entries
>   do not know there scope (class). In other words the connection between
>zend_class_entry.function_table ->> zend_function is a one way link
>because zend_function.scope==NULL :-((
>
> For the moment:
> I know that i can fetch the scop easily if it is missing by using
> apply_func_args_t type functions instead of apply_func_arg_t
> and passing the scope to add_function_info.
> But for me it seems to be a problem in the zend engine.
>
> Example 1:
> [marcus@zaphod php4-HEAD]$ php -r 'class zz_c { function zz_c()
> {echo"zz_inst\n";}; static function zz_sf() {};};$o=new
> zz_c();$l=function_list();sort($l);var_dump($l);' | grep zz
> zz_inst
>string(10) "class zz_c"
>string(10) "class zz_c"
>string(18) "static zz_c::zz_sf"
>string(18) "static zz_c::zz_sf"
>string(2) "zz"
>string(10) "zz_c::zz_c"
>string(10) "zz_c::zz_c"
>
> Example 2: searching for methods of class defined in ext/xslt
> [marcus@zaphod php4-HEAD]$ php -r 'var_dump(function_list());' | grep domnode
>string(7) "domnode"
>string(7) "domnode"
>string(7) "domnode"
>string(7) "domnode"
>string(7) "domnode"
>string(7) "domnode"
>string(7) "domnode"
>string(7) "domnode"
>string(7) "domnode"
>string(7) "domnode"
>string(7) "domnode"
>string(7) "domnode"
>string(7) "domnode"
>string(7) "domnode"
>string(7) "domnode"
>string(7) "domnode"
>string(7) "domnode"
>
>
> /* {{{ add_function_info */
> static int add_function_info(zend_function *func, zval *return_value TSRMLS_DC)
> {
>  char *f;
>  if (func->internal_function.handler !=
> zif_display_disabled_function) {
>  /* ?? internal_function->type = ZEND_INTERNAL_FUNCTION;  */
>  if (func->common.scope) {
>  if (func->common.is_static) {
>  spprintf(&f, 0, "static %s::%s",
> func->common.scope->name, func->common.function_name);
>  } else {
>  spprintf(&f, 0, "%s::%s",
> func->common.scope->name, func->common.function_name);
>  }
>  } else {
>  f = estrdup(func->common.function_name);
>  }
>  add_next_index_string(return_value, f, 0);
>  }
>  return 0;
> }
> /* }}} */
> /* {{{ add_class_info */
> static int add_class_info(zend_class_entry **zclass, zval *return_value
> TSRMLS_DC)
> {
>  char *f;
>  spprintf(&f, 0, "class %s", (*zclass)->name);
>  add_next_index_string(return_value, f, 0);
>  zend_hash_apply_with_argument(&(*zclass)->function_table,
> (apply_func_arg_t)add_function_info, return_value TSRMLS_CC);
>  return 0;
> }
> /* }}} */
> /* {{{ proto array function_list()
> Returns an array of all php functions */
> PHP_FUNCTION(function_list)
> {
>  if (ZEND_NUM_ARGS()) {
>  WRONG_PARAM_COUNT;
>  }
>
>  if (array_init(return_value) == FAILURE) {
>  php_error_docref(NULL TSRMLS_CC, E_ERROR, "Unable to
> initialize array");
>  RETURN_FALSE;
>  }
>
>  zend_hash_apply_with_argument(EG(function_table),
> (apply_func_arg_t)add_function_info, return_value TSRMLS_CC);
>  zend_hash_apply_with_argument(EG(class_table),
> (apply_func_arg_t)add_class_info,return_value TSRMLS_CC);
> }
> /* }}} */
>
>
>
> --->>> mailto:[EMAIL PROTECTED] <<<--
> "We are animals among animals, all children of matter,
> save that we are the more disarmed. But since, unlike animals,
> we know that we must die, let us prepare for that moment
> by enjoying the life that has been given us by chance and for chance."
> Umberto Eco, The island of the day before
> ->>> http://marcus-boerger.de <<<-
>


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

[PHP-DEV] RE: hebrew patch for jewish calendar

[Wez Furlong]

Hey Moshe,

Could you resend your revised patch to Tal (and the list)?

--Wez.



smime.p7s
Description: application/pkcs7-signature

Re: [PHP-DEV] getimagesize() broken in HEAD

[Wez Furlong]

I just merged some streams fixes back from the branch, so
perhaps it was a streams problem after all?

--Wez.

On Mon, 18 Nov 2002, Marcus [iso-8859-1] Börger wrote:

> At 11:20 18.11.2002, Derick Rethans wrote:
> >On Mon, 18 Nov 2002, Rasmus Lerdorf wrote:
> >
> > > getimagesize() works ok in the 4.3 branch, but in HEAD it is returning
> > > weird data.  streams problem?  too tired to track it down right now.
> >
> >It might have something to do with this patch:
> >
> >http://cvs.php.net/diff.php/php4/ext/standard/image.c?login=2&r1=1.72&r2=1.73&ty=h
> >
> >Derick
>
> But i applied the same patch to 4.3 and branch.
> For me both 4.3 and branch are working.
>
>
> --
> 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] XP?

[Wez Furlong]

Plus we were using IRC to bounce ideas off each other at the same time :)

--Wez.

On 11/17/02, "Andrei Zmievski" <[EMAIL PROTECTED]> wrote:
> Who says Xtreme Programming can't work over long distances.. :)
> 
>   iliaa   Sat Nov 16 19:07:33 2002 EDT
> 
> Modified files:  (Branch: PHP_4_3)
>   /php4/main  streams.c 
> Log: MFH
> 
>   wez Sat Nov 16 19:08:42 2002 EDT
> 
> Modified files:  (Branch: PHP_4_3)
>   /php4/main  streams.c 
> Log: Remove debugging printf
> 
>   iliaa   Sat Nov 16 19:11:20 2002 EDT
> 
> Modified files:  (Branch: PHP_4_3)
>   /php4/main  streams.c 
> Log: Fix compile warning.
> 
>   wez Sat Nov 16 20:06:32 2002 EDT
> 
> Modified files:  (Branch: PHP_4_3)
>   /php4/main  streams.c 
> Log: Avoid a potential double fclose().
> 
> -Andrei   http://www.gravitonic.com/
> 
> Any sufficiently advanced bug is
> indistinguishable from a feature.
> -- Rich Kulawiec
> 
> -- 
> 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] mbstring and 4.3.0

[Wez Furlong]

On 11/13/02, "Derick Rethans" <[EMAIL PROTECTED]> wrote:
> On Wed, 13 Nov 2002, Marcus Börger wrote:
> > At 04:11 13.11.2002, Jani Taskinen wrote:
> > 
> > > Since when have we started to use users as guinea-pigs
> > > for testing EXPERIMENTAL extensions without them even
> > > really knowing about it?!!
> > 
> > mbstring is not EXPERIMENTAL and i said let them try it. That
> > does not mean test it. We think it works .
> 
> uhm, I don't think it works stable enough.

Which part of "have used it in production for 2 years with 0 problems"
means that it's not stable? :)

The parts that myself (and Marcus) want to push *are* very stable.
Let's just disable the non-stable, lazy programmer hacky parts by
default and everyone will be happy.

(Still no responses to my no-nonsense suggestion)

--Wez.




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

[PHP-DEV] Critical? Shutdown issue with nsapi (Bug #20274)

[Wez Furlong]

I'm a little concerned about #20274 (running out of file descriptors);
I'm not sure of the cause, but I suspect that there is some kind of
request shutdown issue with threaded servers.

The PR implies that this is a problem with iPlanet under Solaris, but it
really would be a good idea to make sure that other sapis are not
affected in the same way.

Could someone with nsapi, isapi, and any other threaded server see if
they can reproduce this issue?  The test case is essentially a script
that opens files and directories but leaves the handles open so that the
engine cleans them up at request shutdown.  Then keep on making http
requests for the script until you run out of file handles.

Once we have a better picture of the cause of the problem, we can sort
it out.

--Wez.



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

[PHP-DEV] [RFC] php-cli: option to ignore php.ini

[Wez Furlong]

What are your opinions for having some option to prevent the
loading/parsing of php.ini for the CLI version of PHP?

  -n "No Ini File"  - skips parsing php.ini on startup

At the moment, I'm using "-c DOESNOTEXIST" to achieve the same result,
but this is a bit hacky.

--Wez.


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

Re: [PHP-DEV] Freeing memory

[Wez Furlong]

Hi Tony,

What kind of things are you planning to do?
proc_open seems ideal to extend for this purpose, and works on win32.

--Wez.

On 09/11/02, "Tony Leake" <[EMAIL PROTECTED]> wrote:
> The whole picture is that i want to control a child process completely 
> from within php. A bit like popen or proc_open but with 2 independent
> pipes to the child's stdin and stdout that I can read and write to. So
> I'm basically wrapping the c functions pipe(), dup2() and friends. Once
> I have it all working I will offer to add the functions into the pcntl
> extension if they're wanted. 




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

Re: [PHP-DEV] CVS account request

[Wez Furlong]

Hello Sergey,

PHP 4.3 will/does have SSL and TLS support integrated into the fopen
and fsockopen functions. (see the online manual:
http://php.net/fopen and http://php.net/fsockopen).

The current implementation requires that the openssl extension
is built-in to php (rather than shared), and does not allow for
using certificates (as your patch does).

I'm not so keen on the way that you get the fd from the sockets
extension, and would prefer to see those features integrated into
PHP more fully, so...

If you could read through the online docs for streams, take a look
in main/network.c and main/streams.c and come up with an alternative
patch that is integrated into the new streams API, I will review it
and then most likely commit it.  Feel free to ask me questions on
streams (as a hint, the certificate stuff should probably use the
stream_set_option API).

Please also read the README.SUBMITTING-PATCH file before posting
your next patch.

Thanks for your efforts!

--Wez.
"Streams Guy" and openssl extension maintainer

On 11/08/02, "Sergey A. Smitienko" <[EMAIL PROTECTED]> wrote:
> Hello,
>   
>   I want to contribute some functions to openssl and sockets
>   extantions, like SSL/TSL support for internet connections.
>   
>   I've made some patches for 4.2.3 - you can see it on my
>   homepage: www.sergey-smitienko.com.ua/files/.



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

Re: [PHP-DEV] mbstring and 4.3.0

[Wez Furlong]

I see the known-good codeset conversion implementation as a *very* good
reason to have mbstring enabled by default.
(Just look at all the problems with iconv and recode on different systems
out there).

I agree that the magic features for lazy programmers (function overloading
and transparent encoding) are slightly worrying, but they are disabled
by default, and as I have said - I don't use those, but I do use the
conversion functions and *that* configuration works just fine.

The conversion functions are something that really should be there by
default, as it allows people to write portable globalized scripts.
Remember that a large majority of users are vhosted and have not control
over the build of PHP.  By not providing a reliable and portable
codeset conversion API, we are holding back "the masses" from writing
(and distributing) "killer apps" in PHP.

Yes, I can enable mbstring at configure time, and yes, the CJK people
can do likewise, but what about the rest of the world running from vhosts
when they want to use unicode, quoted-printable, uu-encoding,  encodings which are also supported by mbstring?

We took the decision to enable it by default; let's not be short-sighted
and disable it primarily out of ignorance (no offence intended).

I've yet to see someone comment on my suggestions for a practical solution
that would shut up both myself and the people advocating disabling it.

--Wez.

On 11/07/02, "Derick Rethans" <[EMAIL PROTECTED]> wrote:
> On Thu, 7 Nov 2002, Marcus Boerger wrote:
> 
> > To make php be easier usable in non US-ASCII (127chars) environments
> > especially those requiring UCS-2, UTF-8 or other any character mapping
> > other than iso-8859-1 or -15 we should more likly try to integrate mbstring
> > fully in php. As long as we cannot or want not make it a core component
> > such as ext/standard we should enable it by default.
> 
> If people want it they can use --enable-mbstring. I see no reason why it 
> should be enabled by default as long as it's not fully integrated in the 
> core.



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

Re: [PHP-DEV] mbstring and 4.3.0

[Wez Furlong]

I agree with you that the codeset conversion functions should be there
by default (iconv and recode seem to have patchy/variable support on
different platforms; mbstring is reliable since we know exactly what is
supported in there).

I've been using the conversion functions of mbstring in production for
around 2 years now - I've never had a problem with them, so they are
more than stable IMO.

I think disabling mbstring by default would be a not-very-productive
step backwards, but I'm happy to compromize:

The issue is with the function table hacking, so why not either:

 o #ifdef it out and use a configure option to enable the potentially
   dangerous functionality.

 o Provide a zend-api for overloading function entries.
   This was something that came up a while ago on php-dev when
   the namespace purists were trying to ditch the _() function
   in the gettext extension.

   it might look something like this:

   int _zend_overload_function(char *func_name,
 void (*handler)(INTERNAL_FUNCTION_PARAMETERS),
 long apino TSRMLS_DC);

   #define zend_overload_function(func_name, handler) \
 _zend_overload_function((func_name), (handler), \
ZEND_EXTENSION_API_NO TSRMLS_CC)

   In this way, _zend_overload_function can check to see which extension
   API is being used and then bail if it doesn't match (although this
   could be caught more generally by the module version info).

   More importantly, we can hide the gory details of the function table
   hash and implement the overload in a safe way.

--Wez.

On Thu, 7 Nov 2002, Marcus Boerger wrote:

> To make php be easier usable in non US-ASCII (127chars) environments
> especially those requiring UCS-2, UTF-8 or other any character mapping
> other than iso-8859-1 or -15 we should more likly try to integrate mbstring
> fully in php. As long as we cannot or want not make it a core component
> such as ext/standard we should enable it by default.
>
> And it do not see why it is dangerous or why it should harm any test?
> All hose mbstring settings affecting the tests are no set in such a way
> that activating mbstring cannot harm AND mbstring is deply tested for
> its own. When currently any test is affected by mbstring this should be
> reported so we can adjust test settings!
>
> marcus
>
> At 16:04 07.11.2002, Andrei Zmievski wrote:
> >At the PHP Conference in Germany several of us have discussed the
> >current state of mbstring and there was a proposal to not have it
> >enabled by default for 4.3.0 release. It seems that the extension
> >attempts to do "magic" stuff by overloading functions in the executor
> >globals and, as Thies said, that could be dangerous. Also, doesn't it
> >affect run-tests.php script currently?
> >
> >Comments are welcome.



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

Re: [PHP-DEV] Please help document headers_sent()

[Wez Furlong]

Hi Philip,

I think the idea is that you do this:

if (headers_sent($file, $line)) {
  echo "headers were sent by $file:$line";
}

Both $file and $line are optional.

--Wez.

On 06/11/02, "Philip Olson" <[EMAIL PROTECTED]> wrote:
> Hello-
> 
> headers_sent() has two new parameters as of PHP 
> 4.3.0, these are passed in by reference.  I see
> no need to have to do:
> 
>   $file = 'file.php';
>   $line = 4;
> 
>   headers_sent($file, $line);
> 
> When one could simply do this:
> 
>   headers_sent('file.php', 4);
> 
> But we can't, we get this error:
> 
>   Fatal error: Only variables can be passed by reference
> 
> This doesn't seem important, forcing one to use 
> variables here seems odd, why?  Yes & is in the
> proto but afaict it shouldn't be.
> 
> On a related note, I tried and failed to return
> anything other then 1 while using these optional
> parameters.  I can't even tell if it's reading
> the file.  If someone could explain a little more
> that would be very cool.
> 
> Regards,
> Philip
> 
> 
> 
> -- 
> 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] [Sorta OT] Mystery zcontext?

[Wez Furlong]

Hi John,

It's for some funky stuff that won't really come into it's own until
version 5 of PHP.

ATM, you can use stream_context_XXX family of functions to do:

o Set notification callbacks.  These can be used to implement progress
bars for event driven applications.

o Set parameters for the various URL wrappers. For http you can set the
user-agent header.

The context can be shared between multiple streams, and once the curl
library has enough hooks, the curlwrappers will use the context to do
things like store session cookies.

There is a documentation bug about this that might have a little bit
more info.

--Wez.

On Tue, 5 Nov 2002, John Coggeshall wrote:

>
> I was digging around the ext/standard today and I wanted to do something
> with the file access stuff, however I'm a bit lost on something... I'd
> appreciate it if someone could explain this (as it's basically
> undocumented).
>
> What is the fourth parameter for the fopen() function? It's listed as a
> resource, and there is some mention of using callbacks, etc But I
> can't pin it down looking at the code... Anyone care to comment what the
> zcontext parameter does?
>
> John



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

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

[Wez Furlong]

Hi Marcus,

I'm assuming that it's a warning about result being uninitialized; if
that is the case, lets just initialize it to zero in it's declaration.

The cleanup code in errexit: inspects the first byte of tmp_line before
attempting to use it; it might also be a good idea to initialize
tmp_line to "" in it's declaration.

--Wez.

On 11/05/02, "Marcus B?rger" <[EMAIL PROTECTED]> wrote:
> helly Tue Nov  5 06:17:45 2002 EDT
> 
>   Modified files:  
> /php4/ext/standardftp_fopen_wrapper.c 
>   Log:
>   silence
>   #when i get this code right tmp_line is not initialised, too.
>   #Therefore php_stream_wrapper_log_error() will be called with
>   #undefined value, will it?
>   
>   
> Index: php4/ext/standard/ftp_fopen_wrapper.c
> diff -u php4/ext/standard/ftp_fopen_wrapper.c:1.36 
>php4/ext/standard/ftp_fopen_wrapper.c:1.37
> --- php4/ext/standard/ftp_fopen_wrapper.c:1.36Fri Oct  4 17:58:39 2002
> +++ php4/ext/standard/ftp_fopen_wrapper.c Tue Nov  5 06:17:45 2002
> @@ -17,7 +17,7 @@
> |  Hartmut Holzgraefe <[EMAIL PROTECTED]>   |
> +--+
>   */
> -/* $Id: ftp_fopen_wrapper.c,v 1.36 2002/10/04 21:58:39 sesser Exp $ */
> +/* $Id: ftp_fopen_wrapper.c,v 1.37 2002/11/05 11:17:45 helly Exp $ */
>  
>  #include "php.h"
>  #include "php_globals.h"
> @@ -162,8 +162,10 @@
>   resource->port = 21;
>   
>   stream = php_stream_sock_open_host(resource->host, resource->port, 
>SOCK_STREAM, NULL, 0);
> - if (stream == NULL)
> + if (stream == NULL) {
> + result = 0; /* silence */
>   goto errexit;
> + }
>  
>   php_stream_context_set(stream, context);
>   php_stream_notify_info(context, PHP_STREAM_NOTIFY_CONNECT, NULL, 0);
> 
> 
> 
> -- 
> 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] Image corruption when retrieving image files from MYSQL database

[Wez Furlong]

On 04/11/02, "Darren McPhee" <[EMAIL PROTECTED]> wrote:
> I have spent the last 3 days trying to figure this out.  And will probably
> give up very soon.  I have written 2 programs (which are very common PHP

Then please spend the extra couple of minutes to read php.net/support.php
and find the correct forum/list to ask this kind of question.

This list is for people developing the core of php or writing extensions
to it, not for people writing php scripts.

--Wez.





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

Re: [PHP-DEV] ODBTP, a possible solution for MS-SQL and other databases

[Wez Furlong]

Hi Bob,

I'm interested in this becoming more mainstream, although I personally
dislike mssql; the only current alternative that works in a similar way
is one of the packages that Dan mentioned (I forget which) - it was
difficult to configure as it required quite a large amount of fiddling
around on both unix and win32 sides; the TCO was too high.

If your ODBTP is simple to configure, then I'd consider using it for
those clients that insist on a commercial database (using mysql is
causing a few ripples, even though though they need not worry).
However, I'm currently too busy to try it out, so I'm not a suitable
candidate for testing.

As for developer interest; most of the "big boys" are attending a
conference this week/weekend, so don't be disheartened if you still
haven't had much response before the next weekend.

To php-dev: I feel that Robert has had a bit of a cool reception;
opensource development relies on positive feedback to make progress.

Robert must be a skilled programmer to have written this package;
don't forget that he has written a php extension, designed a custom
protocol and written the code for unix and windows to make all those
work together, and all of this without any help from us.
(Most people end up asking at least one question here on php-dev
when they write a php extension)

Let's put aside our animosity towards MS and remain objective; it
seems to me that ODBTP could prove to be a really useful library/
extension.

--Wez. 

On 03/11/02, "Robert Twitty" <[EMAIL PROTECTED]> wrote:
> So far 3 people have shown interest in ODBTP, however, it is the weekend.  I
> am currently working on packaging it in a tar.gz file.  If the response is
> low I will only release it to those who have shown an interest, and if it
> becomes higher than I will release it to the list.  It is very important to
> me that the people who acquire it actually will use it and provide feedback
> within a reasonable time period.  I do not want to feel like I put it in  a
> "black hole."




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

Re: [PHP-DEV] Variable Functions?

[Wez Furlong]

Hi Dan,

http://php.net/create_function,
and see the ZE2 notes on __call/__get/__set handlers.

--Wez.

On 10/31/02, "Dan Hardiker" <[EMAIL PROTECTED]> wrote:
> Hi All,
> 
> Just a thought, but while working reciently with a few ECMA scripting
> languages (eg: ActionScript in Flash MX), I uncovered the amazing uses
> (especially from a security point of view) of variable functions.
> 
> For those that dont know, it allows you to assign a function to a
> variable, rather than to declare it globally, for example:
> 
>  
>   function test ($param, $default=false) {
> // stuff goes here
>   }
>   test("my param");
> 
>   /* could also be written as */
> 
>   $func_test = function ($param, $default) {
> // stuff goes here
>   }
>   $func_test("my param", true);
> 
>   /* removing a function could then be */
> 
>   unset($func_test);
> 
> ?>
> 
> Any form of variable or constant would be able to be used (eg: a function
> inside of an array, or a class method as a property). This would allow the
> very very simple usage of "getter-setters", as they are called in flash.
> 
> EG: You may have the properties $user->birthdate and $user->age, where you
> want the age to be pulled dynamically. At the moment you have to define
> $user->age(), but the following code could be used:
> 
>  
>   class user {
> var $birthdate = "YYMMDDHH";
> var $age = function {
>   // Code to get birthdate
>   $myAge = //  // ;
>   // Return the age
>   return $myAge;
> }
>   }
> 
> ?>
> 
> This may or may not fit into the way PHP is going, but its just an idea -
> and ideas have never been frowned upon, (nor should they be!)
> 
> I think that puts across the general gist of my suggestion... any thoughts
> or comments on the idea?
> 
> 
> -- 
> Dan Hardiker [[EMAIL PROTECTED]]
> ADAM Software & Systems Engineer
> First Creative
> 
> 
> 
> -- 
> 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] hebrew patch for jewish calendar

[Wez Furlong]

Derick: pine can't handle uuencoded attachments :/

moshe: Your mua appears to be MS Outlook Express; you can avoid these
strange problems with attachments by setting it to send base64 encoded
MIME attachments instead of uuencoded "attachments".

As for the patch, can you explain in english what it actually does?
The hebrew text from your original post seems garbled to me (probably
another mua issue), and I couldn't make sense of the source either
(because I can't read hebrew).

--Wez.

On 10/30/02, "Derick Rethans" <[EMAIL PROTECTED]> wrote:
> On Wed, 30 Oct 2002, moshe doron wrote:
> > well 2.3 dayes left,
> > i tried asking some ppl on mail doing that change but didnt got response.
> > can some1 else (may u derick) did it?
> 
> I can if I receive the patch in a normal form.
> 
> Derick
> 
> > > On Mon, 28 Oct 2002, moshe doron wrote:
> > >
> > > > i patched the jdtojewish() function to return the symbolic hebrew data
> > (i.e.
> > > > "ëá çùåï äúùñâ")
> > > > by second optional parameter.
> > > >
> > > > could some1 commit that please?




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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard/tests/file userstreams.phpt

[Wez Furlong]

Is that ZE2?
There is no zend_assign_add_obj_handler function anywhere in my checkout
of HEAD + ZE1, and line 232 of zend_execute is a case statement in
my checkout.

I'm not concerned with ZE2 problems at this time (well, I am, but don't
have the time to support it).  Most likely, this is an issue with the
recent splitting of the opcode handlers; Andi would probably like to
see this backtrace.

--Wez.

On 29/10/02, "Marcus Börger" <[EMAIL PROTECTED]> wrote:
> (gdb) file /usr/src/php4-HEAD/sapi/cli/php
> Reading symbols from /usr/src/php4-HEAD/sapi/cli/php...done.
> (gdb) set args ext/standard/tests/file/userstreams.phpt
> (gdb) run
> Starting program: /usr/src/php4-HEAD/sapi/cli/php 
> ext/standard/tests/file/userstreams.phpt
> [New Thread 1024 (LWP 13760)]
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1024 (LWP 13760)]
> 0x081cb069 in zend_assign_add_obj_handler (execute_data=0xbfffa520,
>  op_array=0x407581bc, tsrm_ls=0x82887b0)
>  at /usr/src/php4-HEAD/Zend/zend_execute.c:232
> 232 if ((*object_ptr)->type == IS_NULL
> (gdb) bt
> #0  0x081cb069 in zend_assign_add_obj_handler (execute_data=0xbfffa520,
>  op_array=0x407581bc, tsrm_ls=0x82887b0)
>  at /usr/src/php4-HEAD/Zend/zend_execute.c:232
> #1  0x081c34de in execute (op_array=0x407581bc, tsrm_ls=0x82887b0)
>  at /usr/src/php4-HEAD/Zend/zend_execute.c:1194
> #2  0x081a9f7c in call_user_function_ex (function_table=0x4073e74c,
>  object_pp=0x40798984, function_name=0xbfffa6a0, retval_ptr_ptr=0xbfffa694,
>  param_count=1, params=0xbfffa698, no_separation=0, symbol_table=0x0,
>  tsrm_ls=0x82887b0) at /usr/src/php4-HEAD/Zend/zend_execute_API.c:646
> #3  0x081944f7 in php_userstreamop_read (stream=0x40799760, buf=0x407cea4c "",
>  count=8192, tsrm_ls=0x82887b0)
>  at /usr/src/php4-HEAD/main/user_streams.c:444
> #4  0x0818cdb9 in php_stream_fill_read_buffer (stream=0x40799760, size=1023,
>  tsrm_ls=0x82887b0) at /usr/src/php4-HEAD/main/streams.c:491
> #5  0x0818d1e0 in _php_stream_get_line (stream=0x40799760, buf=0x407ce610 "",
>  maxlen=1024, returned_len=0xbfffa770, tsrm_ls=0x82887b0)
>  at /usr/src/php4-HEAD/main/streams.c:758
> #6  0x08120a1c in zif_fgets (ht=2, return_value=0x407cc368, this_ptr=0x0,
>  return_value_used=1, tsrm_ls=0x82887b0)
>  at /usr/src/php4-HEAD/ext/standard/file.c:1341
> #7  0x081d4bfa in zend_do_fcall_common_helper (execute_data=0xbfffd7b0,
>  op_array=0x40738864, tsrm_ls=0x82887b0)
>  at /usr/src/php4-HEAD/Zend/zend_execute.c:2414
> ---Type  to continue, or q  to quit---
> #8  0x081d5419 in zend_do_fcall_handler (execute_data=0xbfffd7b0,
>  op_array=0x40738864, tsrm_ls=0x82887b0)
>  at /usr/src/php4-HEAD/Zend/zend_execute.c:2533
> #9  0x081c34de in execute (op_array=0x40738864, tsrm_ls=0x82887b0)
>  at /usr/src/php4-HEAD/Zend/zend_execute.c:1194
> #10 0x081b3177 in zend_execute_scripts (type=8, tsrm_ls=0x82887b0, retval=0x0,
>  file_count=3) at /usr/src/php4-HEAD/Zend/zend.c:862
> #11 0x08183f99 in php_execute_script (primary_file=0xbab0,
>  tsrm_ls=0x82887b0) at /usr/src/php4-HEAD/main/main.c:1541
> #12 0x081dfa30 in main (argc=2, argv=0xbb44)
>  at /usr/src/php4-HEAD/sapi/cli/php_cli.c:695
> #13 0x40561280 in __libc_start_main () from /lib/libc.so.6
> (gdb)
> 
> At 19:02 29.10.2002, you wrote:
> >OK, so how about a backtrace ?
> >
> >--Wez.
> >
> >On Tue, 29 Oct 2002, Marcus [iso-8859-1] Börger wrote:
> >
> > > At 16:36 29.10.2002, Wez Furlong wrote:
> >
> > > >Also, could you strace it too? (just to be sure)
> > >
> > > old_mmap(NULL, 266240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> > > 0) = 0x407d5000
> > > read(3, "...naq gur ebnq orpbzrf zl oevqr"..., 8192) = 8192
> > > lseek(3, 0, SEEK_SET)   = 0
> > > --- SIGSEGV (Segmentation fault) ---
> > > +++ killed by SIGSEGV +++
> > >
> > >




-- 
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/tests/file userstreams.phpt

[Wez Furlong]

OK, so how about a backtrace ?

--Wez.

On Tue, 29 Oct 2002, Marcus [iso-8859-1] Börger wrote:

> At 16:36 29.10.2002, Wez Furlong wrote:

> >Also, could you strace it too? (just to be sure)
>
> old_mmap(NULL, 266240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0x407d5000
> read(3, "...naq gur ebnq orpbzrf zl oevqr"..., 8192) = 8192
> lseek(3, 0, SEEK_SET)   = 0
> --- SIGSEGV (Segmentation fault) ---
> +++ killed by SIGSEGV +++
>
>


--
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/tests/file userstreams.phpt

[Wez Furlong]

On 10/29/02, "Marcus Börger" <[EMAIL PROTECTED]> wrote:
> This test fails with adding
> --INI--
> output_buffering=0
> output_handler=
> zlib.output_compression=
> implicit_flush=0

Works fine here.
 
> and even when removing the three calls to ob_xxx89

Can you email me the output?
Also, could you strace it too? (just to be sure)

--Wez.


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

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard/tests/file userstreams.phpt

[Wez Furlong]

Lets stick to C comments, as those are the preference listed in 
coding standards (and C++ style comments are really only intended
for single line out-commenting anyhow).

The test works fine here; it relies on output buffering working correctly;
when the test passes you see only the expected output.  If it fails, you
see a trace of the seek offsets and expected positioning etc. etc.

The failure of the test for you, and also the strange behaviour when
changing the ob_xxx calls points a finger at the output buffer layer.

Lets just make it a point to discuss something before changing someone
elses code: comments and coding styles are often a touchy subject with
a lot of developers (I'm normally fine with it, but it seemed pointless
in this case, and against our general coding standards.)

--Wez.


On 10/29/02, "Marcus Börger" <[EMAIL PROTECTED]> wrote:
> I started to work on that issue. My first attempt was to check where and
> why the test failed. I used the comment modification because it seems
> the test fails due to some internal failure.
> 
> The reason i did not ask you before was that i considered my changes
> a kind of whitespace change so that any further change can easily be
> seen.
> 
> The question i would like to ask now we already talk about this is:
> When i comment out everythink starting at ob_start() i get some
> output. If not (original) then i don't get any output. What is weired is
> that when i use any print/echo statement after ob_end_xxx() nothing
> is printed...
> 
> The length of the lyrics added by me was only to test whether or not that
> part of the script works.
> 
> marcus
> 
> At 15:25 29.10.2002, Wez Furlong wrote:
> >On 10/29/02, "Marcus B?rger" <[EMAIL PROTECTED]> wrote:
> > >   -Use "//" instead of "/* ... */" comments
> >
> >Why?
> >
> > >   #this test fails for me. Very weired...
> >
> >You changed the test.
> >Why not ask me first about it failing?
> >
> >--Wez.




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

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard/tests/file userstreams.phpt

[Wez Furlong]

On 10/29/02, "Marcus B?rger" <[EMAIL PROTECTED]> wrote:
>   -Use "//" instead of "/* ... */" comments

Why?

>   #this test fails for me. Very weired...

You changed the test.
Why not ask me first about it failing?

--Wez.




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

[PHP-DEV] Re: [PHP-CVS] Discuss on php-dev, not on php-cvs please

[Wez Furlong]

That would be ideal :)

On Tue, 29 Oct 2002, Derick Rethans wrote:

> On Tue, 29 Oct 2002, Wez Furlong wrote:
> > If you need to comment on a commit, can you please change the To/Cc line
> > from php-cvs to php-dev.

> I think we can instruct the listmanager to set a Reply-To header 
> instead, would that be a nice idea?
 


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

Re: [PHP-DEV] I hope this is the last email about this :)

[Wez Furlong]

On 28/10/02, "Zeev Suraski" <[EMAIL PROTECTED]> wrote:
> Thank you for the detailed explanation, I'm sure everybody understands it now.
> 
> Let's go for the voting phase.  I vote we keep PHP-CLI with implicit_flush 
> on by default.

+1

--Wez.


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

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /main streams.c

[Wez Furlong]

Hey Ilia,

Does this prevent opening of things like block and character special files?
If yes, then let's change it to explicitly check for directories instead,
as there are bound to be people out there that want to open things like
/dev/hda1 (for example).

--Wez.

On 28/10/02, "Ilia Alshanetsky" <[EMAIL PROTECTED]> wrote:
>   Fixed bug #20110.
> + if (fstat(fileno(fp), &st) == -1 || !S_ISREG(st.st_mode)) {




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

Re: [PHP-DEV] algebra code

[Wez Furlong]

Get a math text book that explains gaussian elimination, learn it, then
ask your question on php-general.

This list is for development of php itself, not writing programs with PHP.

--Wez.

On 10/24/02, "Diana Castillo" <[EMAIL PROTECTED]> wrote:
> does anyone know where I can get the code to solve equations with three
> unknowns?
> eg.
> 2x+4y+3z=234
> 3x+2y+44z=70
> 8x+33y+9z= 8
> I need the code to solve for x , y and z
> Thanks
> 
> 
> --
> Ve mis pinturas - See my paintings::
> http://www.nvtechnologies.com/hgh/paintingweb
> 
> 
> 
> -- 
> 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: [PATCH] Make mb_convert_case() conform to UnicodeSpec

[Wez Furlong]

If you know what you're doing, go ahead.
But, out of courtesy to the ucdata people who produced the basis of the
code, please Cc: them any patches that they might find useful.
(ucdata is used by the openldap project).

--Wez.

On Thu, 24 Oct 2002, Moriyoshi Koizumi wrote:

> Hi,
> 
> AFAIK, UCDATA itself only offers character conversion facilities, not 
> string conversion ones. Is it our job to discuss how to implement those 
> string conversion functions? If you think so, I'll commit it because 
> I might be one of those who know the right way to handle it.
> 
> Moriyoshi
> 
> 
> Wez Furlong <[EMAIL PROTECTED]> wrote:
> 
> > Hi Moriyoshi,
> > 
> > The code was taken from the ucdata package; I don't really know anything
> > about the internals at this stage.
> > It is probably best to talk to the ucdata guys - I don't have the URL to
> > hand, but I'm sure you can find them using google.
> > 
> > --Wez.
> > 
> > On Thu, 24 Oct 2002, Moriyoshi Koizumi wrote:
> > 
> > > Hello Wez,
> > > 
> > > IMO the current behaviour of mb_convert_case() with MB_CASE_TITLE looks 
> > > a bit strange as per Unicode specification.
> > > 
> > > --snip-- (cited from http://www.unicode.org/unicode/reports/tr21/)
> > > 
> > > S3. toTitlecase(X)
> > > For each character C, find the preceding character B. 
> > > ignore any intervening case-ignorable characters when finding B. 
> > > If B exists, and is cased 
> > > map C to UCD_lower(C) 
> > > Otherwise, 
> > > map C to UCD_title(C) 
> > > 
> > > --snip--
> > > 
> > > The attached patch modifies the conversion routine so that it conforms to 
> > > the document referred above.
> > > 
> > > I don't know what the expected result is, so I refrain from committing it 
> > > immediately. Are there any problems with this?
> > > 
> > > Moriyoshi
> > > 
> > > 
> > 
> > 
> > -- 
> > 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] Re: [PATCH] Make mb_convert_case() conform to Unicode Spec

[Wez Furlong]

Hi Moriyoshi,

The code was taken from the ucdata package; I don't really know anything
about the internals at this stage.
It is probably best to talk to the ucdata guys - I don't have the URL to
hand, but I'm sure you can find them using google.

--Wez.

On Thu, 24 Oct 2002, Moriyoshi Koizumi wrote:

> Hello Wez,
> 
> IMO the current behaviour of mb_convert_case() with MB_CASE_TITLE looks 
> a bit strange as per Unicode specification.
> 
> --snip-- (cited from http://www.unicode.org/unicode/reports/tr21/)
> 
> S3. toTitlecase(X)
> For each character C, find the preceding character B. 
> ignore any intervening case-ignorable characters when finding B. 
> If B exists, and is cased 
> map C to UCD_lower(C) 
> Otherwise, 
> map C to UCD_title(C) 
> 
> --snip--
> 
> The attached patch modifies the conversion routine so that it conforms to 
> the document referred above.
> 
> I don't know what the expected result is, so I refrain from committing it 
> immediately. Are there any problems with this?
> 
> Moriyoshi
> 
> 


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

RE: [PHP-DEV] [PHP-QA] Logs of failed tests PHP 4.3.0pre1 (fwd)

[Wez Furlong]

I've not been following this thread, but wanted to point out that
there is now mb_convert_case() available in the mbstring extension.
It is locale independent and you can specify the charset of the
string whose case you want to convert.

proto string mb_convert_case(string sourcestring, int mode [, string encoding])

mode is one of:
MB_CASE_UPPER, MB_CASE_LOWER, MB_CASE_TITLE.

with that, I withdraw from this thread,

--Wez.

On 20/10/02, "Mike Robinson" <[EMAIL PROTECTED]> wrote:
> Michael Mauch wrote:
> 
> [snip]
> > >> > "en_US.ISO-8859-1" for example?
> > >>
> > >>Yup, thats what its set to.
> > 
> > Hmm. Strange. What does 
> > 
> >   php -r 'echo strtoupper("äöü"),"\n";'
> > 
> > yield on your system? And what system is it, btw?
> 
> 
> It outputs äöü. Stock RedHat-8.0 box, kernel-2.4.18 glibc-2.2.93.
> 
> 
> > We could use a test like strtopper("äöü")=="ÄÖÜ" to check if 
> > the system is able to handle these characters correctly. If 
> > not, the test could be skipped.
> > 
> 
> Adding to ext/xml/tests/007.phpt:
> 
> if (strtoupper("äöü")!="ÄÖÜ") {  
> print "skip\n";  
> }
> 
> fixes this for me.
> 
> Regards
> Mike Robinson
> 
> 
> -- 
> 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] library calls from within php functions

[Wez Furlong]

On 10/20/02, "Tony Leake" <[EMAIL PROTECTED]> wrote:
> and now I'm trying to write functions that will read and write from the
> pipe. So far I have this, it isn't finished as you will see.
> 
> PHP_FUNCTION(pipe_read)
> {
> pipe_r_le_struct *st_pipe_r;
> zval *read;
> zval * res;
> char buf[1024];
> 
> if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "r", &res) ==
> FAILURE) {
> return;
> }
> 
> ZEND_FETCH_RESOURCE(st_pipe_r, pipe_r_le_struct *, &res, -1,
> "pipe_r", le_pipe_r);
> 

Try using curly brackets:

if (!st_pipe_r) {
   RETURN_FALSE;
}

Any I take it you mean this:

read(st_pipe_r->fd, buf, sizeof(buf));

> if(!st_pipe_r) RETURN_FALSE;
> 
> read(fd, buf, sizeof(buf));
> }

Aside from that, I can't see any obvious mistakes.

--Wez.


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