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

2003-03-25 Thread 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 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] 64bit PHP on solaris

2003-03-15 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php



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

2003-03-14 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php



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

2003-03-14 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php



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

2003-03-13 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php



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

2003-03-13 Thread 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] Re: Opening files for write from php modules

2003-03-11 Thread 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 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] Language Auto Detection / www.php.net

2003-03-10 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php



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

2003-03-07 Thread 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 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] bug in zend_API.c (with patch)

2003-03-07 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php



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

2003-03-07 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php



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

2003-03-01 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php



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

2003-02-27 Thread 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 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] date() extension

2003-02-27 Thread 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] date() extension

2003-02-27 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php



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

2003-02-26 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php



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

2003-02-25 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php



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

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

2003-02-23 Thread 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, html\nbody\n?\n\techo \Hello Wo..., 8192) = 58 0.16
 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php



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

2003-02-23 Thread 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=21310edit=1

report that it fixes their problems with solaris.

I've held off from looking at this, as I didn't want to duplicate any
effort you have been making.

--Wez.

On Sun, 16 Feb 2003, Andi Gutmans wrote:

 At 03:41 PM 2/13/2003 -0500, James E. Flemer wrote:
 RCS file: /repository/TSRM/tsrm_virtual_cwd.c,v
 retrieving revision 1.41
 diff -u -b -r1.41 tsrm_virtual_cwd.c
 --- TSRM/tsrm_virtual_cwd.c 6 Nov 2002 18:07:22 -   1.41
 +++ TSRM/tsrm_virtual_cwd.c 13 Feb 2003 20:40:07 -
 @@ -303,7 +303,7 @@
  return (0);
 
   #if !defined(TSRM_WIN32)  !defined(NETWARE)
 -   if (IS_ABSOLUTE_PATH(path, path_length)) {
 +   if (IS_ABSOLUTE_PATH(path, path_length) || (state-cwd_length  1)) {
  if (use_realpath  realpath(path, resolved_path)) {
  path = resolved_path;
  path_length = strlen(path);

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

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

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

 Andi


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





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



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

2003-02-21 Thread 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 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] date() extension

2003-02-17 Thread 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 http://www.php.net/
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/

2003-02-16 Thread Wez Furlong
Should be fixed now.

If any more of these occur, the problem is that winsock2.h needs to be
included before windows.h (which itself includes winsock.h).
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 winsock2.h as one of the first things in php.h, 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] [PATCH] make the win32 project working again afterdate_sun*()'s

2003-02-16 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




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

2003-02-14 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




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

2003-02-12 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




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

2003-02-11 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] proc_open() patch

2003-02-10 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




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

2003-02-10 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




[PHP-DEV] ChangeLog again

2003-02-09 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




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

2003-02-07 Thread 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-cvsm=104407155303062w=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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




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

2003-02-06 Thread 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.

 ?php
   $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 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] Question on bug list

2003-01-31 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




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

2003-01-30 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php


Re: [PHP-DEV] Compiling php4activescript

2003-01-27 Thread 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 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] php_stream size

2003-01-25 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




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

2003-01-23 Thread 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 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] PHP4 + PHP5

2003-01-14 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




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

2003-01-13 Thread 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 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] mailparse

2003-01-09 Thread 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 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] Terminal text objects (PHP CDK NCURSES)

2003-01-09 Thread 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.gztype=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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




[PHP-DEV] Re: Stream filters, converters and i18n.

2003-01-09 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




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

2003-01-07 Thread 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 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] stream filter problem

2003-01-04 Thread 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.

 ?php
 stream_filter_append(STDOUT, string.segfaulting);
 fwrite(STDOUT, test);
 ?

 Thanks,

 Moriyoshi



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




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

2003-01-02 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




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

2003-01-02 Thread 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 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.0, RedHat 7.3:Fatal error: Nesting level too deep- recursive dependency? in Unknown on line 0, even with empty file

2003-01-02 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




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

2003-01-01 Thread 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.devarticle=87097


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




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

2003-01-01 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




[PHP-DEV] ChangeLog

2003-01-01 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




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

2002-12-23 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




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

2002-12-22 Thread 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 --

 ?php echo abcde; ?

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

 br /
 bWarning/b:  (null)() [a
 href='http://www.php.net/ref.outcontrol'ref.outcontrol/a]: Cannot
 change zlib.output_compression - headers already sent in bUnknown/b
 on line b0/bbr /
 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=21139edit=1





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




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

2002-12-19 Thread 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 = script language=\javascript\\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 .= /script\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 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

2002-12-19 Thread 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 http://www.php.net/
 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 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

2002-12-19 Thread 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 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

2002-12-19 Thread 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] CGI and CLI (compromise proposal)

2002-12-19 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




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

2002-12-11 Thread 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.

aolme too/aol

[imagine large quantities of quoted text here]


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




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

2002-12-09 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] 4.3 when?

2002-12-09 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] 4.3 when?

2002-12-09 Thread 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 +, 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] OpenSSL wrappers for PHP 4

2002-12-02 Thread 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 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: Modules/Extensions not in 4.3

2002-11-29 Thread 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 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] Bug #20308 (Feature Request)

2002-11-29 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




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

2002-11-29 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] PHP 5 - when?

2002-11-27 Thread 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 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] Concrete suggestion re: i18n messages

2002-11-26 Thread 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 err_code key in
 php-php.error_lang.cat.  If it exists, the value will be
 used instead of the format fmt.  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 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] [PATCH 4.3.0] Win32 CoInitalize/CoUninitialize CallMove

2002-11-25 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] ZE2 and classes

2002-11-19 Thread 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()
 {echozz_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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] Mailparse extension

2002-11-19 Thread 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 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] getimagesize() broken in HEAD

2002-11-18 Thread 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=2r1=1.72r2=1.73ty=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 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: hebrew patch for jewish calendar

2002-11-18 Thread 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] XP?

2002-11-17 Thread 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 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] mbstring and 4.3.0

2002-11-13 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




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

2002-11-12 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




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

2002-11-11 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] Freeing memory

2002-11-09 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] mbstring and 4.3.0

2002-11-08 Thread 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, name of your
favourite encoding here 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] CVS account request

2002-11-08 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] mbstring and 4.3.0

2002-11-07 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




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

2002-11-06 Thread 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 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: [PHP-CVS] cvs: php4 /ext/standard ftp_fopen_wrapper.c

2002-11-05 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] [Sorta OT] Mystery zcontext?

2002-11-05 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




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

2002-11-03 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] Image corruption when retrieving image files from MYSQL database

2002-11-03 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] Variable Functions?

2002-10-31 Thread 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:
 
 ?php
 
   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:
 
 ?php
 
   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 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] hebrew patch for jewish calendar

2002-10-30 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




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

2002-10-29 Thread 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




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

2002-10-29 Thread 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 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

2002-10-29 Thread 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




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

2002-10-29 Thread 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 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

2002-10-29 Thread 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

2002-10-29 Thread 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 return to continue, or q return 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




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

2002-10-27 Thread 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 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 :)

2002-10-27 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] algebra code

2002-10-24 Thread 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 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

2002-10-23 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




Re: [PHP-DEV] Re: [PATCH] Make mb_convert_case() conform to UnicodeSpec

2002-10-23 Thread 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




Re: [PHP-DEV] library calls from within php functions

2002-10-20 Thread Wez Furlong
Hi Tony,

There's not much we can tell you about this unless you post the
rest of the lines of that function.

Perhaps you did not include php.h ?

Note:  always prefer this:

  read(fd, buf, sizeof(buf));

to this:

  read(fd, buf, 1024);

The former is immune to buffer overruns if you change the size of
buf at a later date, and is much more readable.

--Wez. 

On 10/20/02, Tony Leake [EMAIL PROTECTED] wrote:
 Hi, 
 
 I am working on an extension that makes use of the pipe, read and write 
 library calls on a linux platform. 
 
 When I try to put this line 
 read(fd, buf, 1024);
 inside a php function ( PHP_FUNCTION(read_pipe) ) it fails to compile
 with the following warning:
 called object is not a function.
 
 If I move the same line into a standard c function it compiles without
 error. 
 
 So my question is, is there some problem trying to make library calls
 from within php functions? although other calls seem to work fine.
 
 Thanks for any help
 Tony 
 
 
 -- 
 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] library calls from within php functions

2002-10-20 Thread 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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php




  1   2   3   4   5   6   >