[PHP-DEV] poweroff for some days

[Marcus Boerger]

I am moving to my new flat no and therefore beeing
offline for some days. They said internet is back on
wednesday but who knows...

Hope i did not leave anything important open.
I already had to poweroff linux and no shutting the rest
of my stuff.

marcus


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

RE: [PHP-DEV] [PATCH] ext/xslt - xslt_set_object

[David Viner]

after talking with other xslt developers, and ensuring backwards
compatibility, I have commited this change to the ext/xslt extension.

dave


-Original Message-
From: David Viner [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 03, 2002 11:00 AM
To: Php-Dev@lists. php. net
Subject: [PHP-DEV] [PATCH] ext/xslt - xslt_set_object


Here's a short patch to the XSLT extension that allows a user to call
xslt_set_object($xh,$obj);
This works in a manner similar to the 'xml_set_object' function. (Only
difference is that the second argument is not passed by reference.)

dave


= BEGIN PATCH =
Index: ext/xslt/php_sablot.h
===
RCS file: /repository/php4/ext/xslt/php_sablot.h,v
retrieving revision 1.11
diff -B -b -u -r1.11 php_sablot.h
--- ext/xslt/php_sablot.h   22 Aug 2002 09:54:04 -  1.11
+++ ext/xslt/php_sablot.h   3 Oct 2002 17:57:27 -
@@ -62,6 +62,7 @@
 PHP_FUNCTION(xslt_error);
 PHP_FUNCTION(xslt_errno);
 PHP_FUNCTION(xslt_free);
+PHP_FUNCTION(xslt_set_object);
 PHP_FUNCTION(xslt_backend_version);
 PHP_FUNCTION(xslt_backend_name);

@@ -112,6 +114,7 @@
struct xslt_handlers  *handlers;
struct xslt_processor  processor;
struct xslt_error *err;
+   zval  *object;
 } php_xslt;

 #else
Index: ext/xslt/php_xslt.h
===
RCS file: /repository/php4/ext/xslt/php_xslt.h,v
retrieving revision 1.9
diff -B -b -u -r1.9 php_xslt.h
--- ext/xslt/php_xslt.h 28 Feb 2002 08:27:00 -  1.9
+++ ext/xslt/php_xslt.h 3 Oct 2002 17:57:27 -
@@ -51,7 +51,7 @@

 extern void xslt_assign_handler(struct xslt_function **, zval **);
 extern void xslt_free_handler(struct xslt_function *);
-extern void xslt_call_function(char *, zval *, int, zval **, zval **);
+extern void xslt_call_function(char *, zval *, zval *, int, zval **, zval
**);

 extern void xslt_debug(char *, char *, ...);

Index: ext/xslt/sablot.c
===
RCS file: /repository/php4/ext/xslt/sablot.c,v
retrieving revision 1.52
diff -B -b -u -r1.52 sablot.c
--- ext/xslt/sablot.c   22 Aug 2002 09:54:04 -  1.52
+++ ext/xslt/sablot.c   3 Oct 2002 17:57:27 -
@@ -87,6 +88,7 @@
PHP_FE(xslt_error,   NULL)
PHP_FE(xslt_errno,   NULL)
PHP_FE(xslt_free,NULL)
+   PHP_FE(xslt_set_object,  NULL)
PHP_FE(xslt_backend_version, NULL)
PHP_FE(xslt_backend_name,NULL)
{NULL, NULL, NULL}
@@ -182,6 +184,7 @@
handle   = ecalloc(1, sizeof(php_xslt));
handle->handlers = ecalloc(1, sizeof(struct xslt_handlers));
handle->err  = ecalloc(1, sizeof(struct xslt_error));
+   handle->object   = NULL;

XSLT_LOG(handle).path = NULL;

@@ -610,6 +613,32 @@
 }
 /* }}} */

+/* {{{ proto void xslt_set_object(resource parser, object &obj)
+   sets the object in which to resolve callback functions */
+PHP_FUNCTION(xslt_set_object)
+{
+   zval  **processor_p;  /* Resource pointer to a PHP-XSLT processor */
+   zval  **myobj;/* The object that will handle the callback */
+   php_xslt   *handle;   /* A PHP-XSLT processor */
+
+   if (ZEND_NUM_ARGS() != 2 ||
+   zend_get_parameters_ex(2, &processor_p, &myobj) == FAILURE) {
+   WRONG_PARAM_COUNT;
+   }
+   /* make sure the second argument is an object */
+   if (Z_TYPE_PP(myobj) != IS_OBJECT) {
+   php_error(E_WARNING,"arg 2 has wrong type");
+   RETURN_FALSE;
+   }
+
+   ZEND_FETCH_RESOURCE(handle, php_xslt *, processor_p, -1, le_xslt_name,
le_xslt);
+
+   handle->object = *myobj;
+
+   RETURN_TRUE;
+}
+/* }}} */
+
 /* {{{ proto void xslt_backend_version()
Returns the version number of Sablotron (if available) */
 PHP_FUNCTION(xslt_backend_version)
@@ -742,7 +771,7 @@
ZVAL_STRING(argv[1], (char *) scheme, 1);
ZVAL_STRING(argv[2], (char *) rest, 1);

-   xslt_call_function("scheme get all", XSLT_SCHEME(handle).get_all,
+   xslt_call_function("scheme get all", XSLT_SCHEME(handle).get_all,
handle->object,
   3, argv, &retval);

/* Save the return value in the buffer (copying it) */
@@ -820,7 +849,7 @@
ZVAL_STRING(argv[2], (char *) rest, 1);

/* Call the function */
-   xslt_call_function("scheme open", XSLT_SCHEME(handle).open,
+   xslt_call_function("scheme open", XSLT_SCHEME(handle).open,
handle->object,
   3, argv, &retval);

/* Return value is a resource pointer to an open file */
@@ -864,7 +893,7 @@
ZVAL_STRINGL(argv[2], buffer, *byte_count, 0);

/* Call the function */
-   xslt_call_function("scheme get", XSLT_SCHEME(handle).get,
+   xslt_call_function(

[PHP-DEV] Re: Streams: Further considerations

[Wez Furlong]

On 04/10/02, "Sascha Schumann" <[EMAIL PROTECTED]> wrote:
> 1. Use fgetc in stream_gets for stdio stream ops
> 2. Add file descriptor-based stream ops

> 3. Redirect _php_stream_fopen_from_file/pipe to new stream
> ops, if possible

So, if fileno() returns a valid fd, we will use only read(2)/write(2),
otherwise we will use fgetc()/fread()/fwrite().
The latter should be an extremely rare occurrence - should be for
fopencookied or gnu memory based IO streams.

> > The stdio buffering could be restored when the stream is cast
> > for use by third-party libraries.
> 
> I'm not sure what you are referring to -- do these libraries
> make use of "FILE *" directly?

Potentially, yes.  One of the features of streams is that it allows
an extension to access the underlying handle (fd, FILE * or whatever),
and (to a limited extent) is able to synthesize/emulate the handle.
The whole point is to allow the stream to be passed into libraries
such as PDF, GD and others where the API is designed for a particular
handle type.

--Wez.


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

RE: [PHP-DEV] Development FAQ?

[Joseph Tate]

There are a few ways to do it.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsdebug/htm
l/_atl_using_debugbreak.asp

Add "_asm int 3;" where you want to break.

Use a dialog to pause execution until you can attach the debugger to it:
#ifdef _DEBUG
char szMessage [256];
wsprintf (szMessage, "Please attach a debbuger to the process 0x%X (%s)
and click OK",
  GetCurrentProcessId(), argv[0]);
MessageBox(NULL, szMessage, "CGI Debug Time!",
   MB_OK|MB_SERVICE_NOTIFICATION);
#endif

Or add a registry key (only works with dlls).  I can't find it in the MSDN
right now, but it's set up in \\HKLM\Software\Microsoft\Windows
NT\CurrentVersion\Image File Execution Options\
then just add a DWORD type entry named BreakOnDllLoad 1 breaks 0 does not
break when the dll is loaded.

Basically debugging is based on your ability to stop exection or attach to a
running process.  Hopefully I've given you a few good starting places.


> -Original Message-
> From: Jon [mailto:[EMAIL PROTECTED]]
> Sent: Friday, October 04, 2002 6:39 PM
> To: [EMAIL PROTECTED]
> Subject: [PHP-DEV] Development FAQ?
>
>
> Hello,
>
> Is there a PHP Dev FAQ somewhere?
>
> If not, then I would like to ask your help.
>
> I have PHP set up and compiling on my Win2k box.  My question is, how do I
> debug php.exe while it's running as a CGI application?  Can you
> give me some
> tips on how to set up my environment for debugging?
>
> Thanks,
>
> Jon
>
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php


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

[PHP-DEV] CVS Account Request: ramysaweres

[Ramy Saweres]

I need CVS to join the team that translate the PHP manual to Arabic language .

Ramy.

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

[PHP-DEV] Development FAQ?

[Jon]

Hello,

Is there a PHP Dev FAQ somewhere?

If not, then I would like to ask your help.

I have PHP set up and compiling on my Win2k box.  My question is, how do I
debug php.exe while it's running as a CGI application?  Can you give me some
tips on how to set up my environment for debugging?

Thanks,

Jon



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

[PHP-DEV] Re: Streams: Further considerations

[Sascha Schumann]

> - Disable buffering for stdio streams (setvbuf(3) or similar).
> - read(2) using the fd obtained from fileno(3) (where valid).

Ok, here is a plan:

1. Use fgetc in stream_gets for stdio stream ops
2. Add file descriptor-based stream ops
3. Redirect _php_stream_fopen_from_file/pipe to new stream
ops, if possible

The first point is trivial to implement.  The rest ensures
that no fread/read calls are mixed which could lead to some
pretty obscure bugs.

> The stdio buffering could be restored when the stream is cast
> for use by third-party libraries.

I'm not sure what you are referring to -- do these libraries
make use of "FILE *" directly?

- Sascha



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

[PHP-DEV] Re: Streams: Further considerations

[Wez Furlong]

That's pretty much what streams was doing a couple of weeks ago.
The reason it was changed was because the stdio fgets doesn't handle
non-native EOL conventions :-/.

What are your thoughts on the following:

- Disable buffering for stdio streams (setvbuf(3) or similar).
- read(2) using the fd obtained from fileno(3) (where valid).

The stdio buffering could be restored when the stream is cast
for use by third-party libraries.

--Wez.

On 10/04/02, "Sascha Schumann" <[EMAIL PROTECTED]> wrote:
> Streams' gets function does not work with stdio, because it
> uses fread(3) instead of fgets(3).  Like fill_read_buffer
> earlier, fread(3) does not return, unless an error occurs or
> the amount of data has been read completely.  It is basically
> impossible to implement an _efficient_ fgets-like function
> using fread(3).
> 
> Additionally, stdio does its own buffering -- there is no
> reason to add another buffer layer above it.  The streams
> buffer needs to be disabled, because fgets/fread would
> otherwise interact wrongly.
> 
> The attached patch does this:
> 
> - Disables buffering for stdio using PHP_STREAM_FLAG_NO_BUFFER
> - Adds a gets hook to stream ops
> - Adds a gets implementation to stdio ops
> - Makes stream_gets use that hook, if available
> - Inverts the semantic of fill_read_buffer regarding blocking
> 
> "make test" and entering data using stdin works.
> 
> Comments, please.
> 
> - Sascha




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

[PHP-DEV] Streams: Further considerations

[Sascha Schumann]

Streams' gets function does not work with stdio, because it
uses fread(3) instead of fgets(3).  Like fill_read_buffer
earlier, fread(3) does not return, unless an error occurs or
the amount of data has been read completely.  It is basically
impossible to implement an _efficient_ fgets-like function
using fread(3).

Additionally, stdio does its own buffering -- there is no
reason to add another buffer layer above it.  The streams
buffer needs to be disabled, because fgets/fread would
otherwise interact wrongly.

The attached patch does this:

- Disables buffering for stdio using PHP_STREAM_FLAG_NO_BUFFER
- Adds a gets hook to stream ops
- Adds a gets implementation to stdio ops
- Makes stream_gets use that hook, if available
- Inverts the semantic of fill_read_buffer regarding blocking

"make test" and entering data using stdin works.

Comments, please.

- Sascha


Index: main/network.c
===
RCS file: /repository/php4/main/network.c,v
retrieving revision 1.73
diff -u -r1.73 network.c
--- main/network.c  4 Oct 2002 19:08:43 -   1.73
+++ main/network.c  4 Oct 2002 20:29:10 -
@@ -542,7 +542,6 @@
sock->socket = socket;
 
stream = php_stream_alloc_rel(&php_stream_socket_ops, sock, persistent_id, 
"r+");
-   stream->flags |= PHP_STREAM_FLAG_AVOID_BLOCKING;
 
if (stream == NULL) 
pefree(sock, persistent_id ? 1 : 0);
Index: main/php_streams.h
===
RCS file: /repository/php4/main/php_streams.h,v
retrieving revision 1.53
diff -u -r1.53 php_streams.h
--- main/php_streams.h  4 Oct 2002 18:59:34 -   1.53
+++ main/php_streams.h  4 Oct 2002 20:29:10 -
@@ -153,6 +153,7 @@
int (*cast)(php_stream *stream, int castas, void **ret TSRMLS_DC);
int (*stat)(php_stream *stream, php_stream_statbuf *ssb TSRMLS_DC);
int (*set_option)(php_stream *stream, int option, int value, void *ptrparam 
TSRMLS_DC);
+   size_t (*gets)(php_stream *stream, char *buf, size_t count TSRMLS_DC);
 } php_stream_ops;
 
 typedef struct _php_stream_wrapper_ops {
@@ -225,11 +226,13 @@
 #define PHP_STREAM_FLAG_DETECT_EOL 4
 #define PHP_STREAM_FLAG_EOL_MAC8
 
-/* set this when the stream might represent "interactive" data.
- * When set, the read buffer will avoid certain operations that
- * might otherwise cause the read to block for much longer than
- * is strictly required. */
-#define PHP_STREAM_FLAG_AVOID_BLOCKING 16
+/*
+ * By default, your read operation will be called once to
+ * retrieve a chunk of data. If you do not immediately return
+ * all available data during one read operation and you want
+ * us to call it multiple times, use this flag.
+ */
+#define PHP_STREAM_FLAG_DO_BLOCKING16

 struct _php_stream  {
php_stream_ops *ops;
Index: main/streams.c
===
RCS file: /repository/php4/main/streams.c,v
retrieving revision 1.95
diff -u -r1.95 streams.c
--- main/streams.c  4 Oct 2002 19:48:59 -   1.95
+++ main/streams.c  4 Oct 2002 20:29:12 -
@@ -497,7 +497,7 @@

stream->writepos += justread;

-   if (stream->flags & PHP_STREAM_FLAG_AVOID_BLOCKING)
+   if (!(stream->flags & PHP_STREAM_FLAG_DO_BLOCKING))
break;
}
 }
@@ -657,10 +657,21 @@
 {
size_t avail = 0;
int did_copy = 0;
-   
+
if (maxlen == 0)
return NULL;
 
+   if (stream->ops->gets) {
+   size_t n;
+
+   n = stream->ops->gets(stream, buf, maxlen TSRMLS_CC);
+
+   if (n == 0)
+   return NULL;
+
+   return buf + n;
+   }
+
/*
 * If the underlying stream operations block when no new data is readable,
 * we need to take extra precautions.
@@ -1149,6 +1160,8 @@
 PHPAPI php_stream *_php_stream_fopen_from_file(FILE *file, const char *mode 
STREAMS_DC TSRMLS_DC)
 {
php_stdio_stream_data *self;
+   php_stream *stream;
+   
 #ifdef S_ISFIFO
int fd;
 #endif
@@ -1167,18 +1180,25 @@
}
 #endif

-   return php_stream_alloc_rel(&php_stream_stdio_ops, self, 0, mode);
+   stream = php_stream_alloc_rel(&php_stream_stdio_ops, self, 0, mode);
+   stream->flags |= PHP_STREAM_FLAG_NO_BUFFER;
+   return stream;
 }
 
 PHPAPI php_stream *_php_stream_fopen_from_pipe(FILE *file, const char *mode 
STREAMS_DC TSRMLS_DC)
 {
php_stdio_stream_data *self;
+   php_stream *stream;

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

[Marcus Börger]

(switching to php-dev)

At 20:36 04.10.2002, Markus Fischer wrote:
> Why this sudden change anyway? I mean I understand what you
> mean. But this would mean to go through it everywhere or
> again we will have inconsistency if me miss some.
>
> The (usual) developer knows (should know) that not setting
> the return_value defaults to IS_NULL . Of course documenting
> this (if not already, I don't know) is good [tm] and the way
> I would prefer it.

I allways used to check for xxx() !== false since that is used
in the documentation in some examples. See strpos() ...

If the parser error is represented as NULL you cannot do something like:
if (xxx() !== false) ...
instead you would have to use

for some function documentations about return values:

array_flip() returns FALSE if it fails
bool array_multisort ( array ar1 [, mixed arg [, mixed ... [, array 
...]]])   [snip] Returns TRUE on success or FALSE on failure.
array pop returns NULL in a normal opertion but also false or arrays...
mixed array_search ( mixed needle, array haystack [, bool strict])
 Searches haystack for needle and returns the key if it is found in 
the array, FALSE otherwise.
 Note: Prior to PHP 4.2.0, array_search() returns NULL on failure 
instead of FALSE
string fgets ( int fp [, int length])
 If an error occurs, returns FALSE.
int filesize ( string filename)
 Returns the size of the file in bytes, or FALSE in case of an error.
int fopen ( string filename, string mode [, int use_include_path [, 
resource zcontext]])
 If the open fails, the function returns FALSE.



Functions in question:
getenv() returned FALSE before and that was documented.
string getopt ( string options)
 Returns an associative array of option / argument pairs based on 
the options format specified in options, or FALSE on an error.
mixed highlight_file ( string filename [, bool return])
 ...then highlight_file() will return TRUE on success, FALSE on 
failure.
mixed highlight_string ( string str [, bool return])
 ...then highlight_string() will return TRUE on success, FALSE on 
failure.
ini_get_all : no info about return value on failure
getprotobyname : no info about return value on failure
print_r: no info about the meaning of the boolean return value at all
parse_ini_file : no info about return value on failure but php will exit is 
that really so?



So i would go for changing all return values to FALSE on any error
where possible. Possible means some functions may return FALSE
but not NULL since their normal return value is boolean and false
is a normal return value (so these should use NULL instead).

Additionally i started to use a special documentation form
false | returntype functionname(...)
for some of my functions.



>On Fri, Oct 04, 2002 at 08:33:42PM +0200, Marcus Börger wrote :
> > In this case i would vote for RETURN_NULL(); instead
> > of simply using return;
> >
> > At 20:20 04.10.2002, Markus Fischer wrote:
> > >No function never called RETURN_FALSE if
> > >zend_parse_parameters couldn't successfully parse the passed
> > >parameters.
> > >
> > >Are we going to change this behaviour globally?
> > >
> > >Function up and including today returned NULL if there was a
> > >problem with parsing the parameters.
> > >
> > >This could well break BC in my eyes. Is this absolutely
> > >necessary ?
> > >
> > >On Fri, Oct 04, 2002 at 05:17:01PM -, Marcus Börger wrote :
> > >> helly Fri Oct  4 13:17:01 2002 EDT
> > >>
> > >>   Modified files:
> > >> /php4/ext/standardbasic_functions.c
> > >>   Log:
> > >>   return FALSE on error
> > >>
> > >>
> > >> Index: php4/ext/standard/basic_functions.c
> > >> diff -u php4/ext/standard/basic_functions.c:1.522
> > >php4/ext/standard/basic_functions.c:1.523
> > >> --- php4/ext/standard/basic_functions.c:1.522 Thu Oct  3 09:31:59 2002
> > >> +++ php4/ext/standard/basic_functions.c   Fri Oct  4 13:17:01 2002
> > >> @@ -17,7 +17,7 @@
> > >>
> > >+--+
> > >>   */
> > >>
> > >> -/* $Id: basic_functions.c,v 1.522 2002/10/03 13:31:59 yohgaki Exp $ */
> > >> +/* $Id: basic_functions.c,v 1.523 2002/10/04 17:17:01 helly Exp $ */
> > >>
> > >>  #include "php.h"
> > >>  #include "php_streams.h"
> > >> @@ -1377,7 +1377,7 @@
> > >>
> > >>   if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "s",
> > >> &options,
> > >&options_len) == FAILURE) {
> > >> - return;
> > >> + RETURN_FALSE;
> > >[...]
>
>--
>GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
> Derick, while ($xml) $ass->get_new_ideas();
><[James]> Markus: IE on_user_fart()
>-- People doesn't seem to like the new XHTML2 specs :) --
>
>--
>PHP CVS Mailing List (http://www.php.net/)
>To unsubscribe, visit: http://www.php.net/unsub.php

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

[Edin Kadribasic]

On Friday 04 October 2002 18:06, Ilia A. wrote:
> The attached patch adds .phps file support for Apache 2, allowing Apache 2
> users to show prettified source of their scripts, just like their Apache 1
> counterparts can.
>
> It is a fairly simple patch, that adds just 2 cmp overhead for this
> functionality, so its not too bad imho.
> Please review the patch and let me know if there are any objections to it's
> addition.

I tested the patch and it seems to be working fine.

Edin

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

[PHP-DEV] blocking and fill buffer

[Sascha Schumann]

Ilia,

unfortunately, I cannot view your patch -- it was not
Cc'ed to me and news.php.net does not know about text/x-diff
yet (Jim, could you please add that?).

Wez,

it looks like the default blocking behaviour of fill_read_buffer
is causing several bugs :-)

Reading from stdin blocks, because the function will not
return unless a specified amount of data has been read.

For files and ttys, a single read should be sufficient, so we
need PHP_STREAM_FLAG_AVOID_BLOCKING for stdio operations as
well.

Or: Reconsider the standard semantics of that function.  It
is very likely that only a few special cases will require the
use of multiple read operations.

- Sascha


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

Re: [PHP-DEV] #19746 (fwd)

[Ilia A.]

Would this be a more appropriate solution to the problem in that case?
This forces a non-blocking mode on all non static streams such as 
FTP/HTTP/std*.

Ilia

On October 4, 2002 03:11 pm, Sascha Schumann wrote:
> Iliaa,
>
> looking at a syscall trace from PHP 4.2, the difference in
> handling php://std* is that 4.2 uses non-blocking mode by
> default, while streams block by default.
>
> 4.2: fcntl64(0x3, 0x3, 0x8050fe5, 0) = 2
>
> 4.3: fcntl64(0x3, 0x3, 0xb7f4, 0x3)  = 2
>
> E.g.
>
> $fp = fopen("php://stdin", "r");
> stream_set_blocking($fp, false);
> print fgets($fp, 500);
>
> works as in PHP 4.2 without the set_blocking call.
>
> Wez, any idea on what is causing this?
>
> - Sascha


Index: php_fopen_wrapper.c
===
RCS file: /repository/php4/ext/standard/php_fopen_wrapper.c,v
retrieving revision 1.25
diff -u -3 -p -r1.25 php_fopen_wrapper.c
--- php_fopen_wrapper.c	26 Sep 2002 10:14:41 -	1.25
+++ php_fopen_wrapper.c	4 Oct 2002 19:17:34 -
@@ -89,6 +89,7 @@ php_stream * php_stream_url_wrap_php(php
 		stream = php_stream_fopen_from_file(fp, mode);
 		if (stream == NULL)
 			fclose(fp);
+		php_stream_set_option(stream, PHP_STREAM_OPTION_BLOCKING, 0, NULL);	
 	}
 	return stream;
 }



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

[PHP-DEV] #19746 (fwd)

[Sascha Schumann]

Iliaa,

looking at a syscall trace from PHP 4.2, the difference in
handling php://std* is that 4.2 uses non-blocking mode by
default, while streams block by default.

4.2: fcntl64(0x3, 0x3, 0x8050fe5, 0) = 2

4.3: fcntl64(0x3, 0x3, 0xb7f4, 0x3)  = 2

E.g.

$fp = fopen("php://stdin", "r");
stream_set_blocking($fp, false);
print fgets($fp, 500);

works as in PHP 4.2 without the set_blocking call.

Wez, any idea on what is causing this?

- Sascha



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

Re: [PHP-DEV] Re: Fixing socket reads

[Wez Furlong]

That buffering code is new as of a couple of weeks ago, in response to
doing something about handling mac EOL conventions, so I'm not surprised
there have been a couple of teething troubles there :-/

Sascha: thanks for fixing fgets; I've removed the dont_block member of the
stream ops and replaced it with a (bitfield) flag in the stream itself,
as it feels tidier that way.

--Wez.

On 10/04/02, "Sascha Schumann" <[EMAIL PROTECTED]> wrote:
> On Fri, 4 Oct 2002, Rasmus Lerdorf wrote:
> 
> > > Guys,
> > >
> > > Are we going to have the streams stuff sorted before tomorrow?
> >
> > I don't think there is anything too magical about Saturday.  The magic was
> > setting a date which has spurred a lot of good fixes.  If we need to give
> > folks a couple more days to finish up stuff then we do that.
> 
> Well, my fixes were spurred because my applications broke in
> the deployment phase.  I am extremely surprised by the
> relative low quality of the 4.3 branch.  Many major bugs have
> been lurking in there for months.
> 
> - Sascha




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

[PHP-DEV] Re: fgets on sockets borked

[Sascha Schumann]

> B. reading a byte at a time (that's how it was done previously).

Well, actually, that is not the case.  Since PHP
3.0.something, PHP used a socket buffering system for
reading data from the network.  Since then, no single byte
reads were necessary.

Watch PHP 4.2 fgets'ing from the network:

select(4, [3], NULL, NULL, NULL)= 1 (in [3])
recv(3, "+OK Cubic Circle\'s v1.31 1998/05"..., 8192, 0) = 77
select(4, [3], NULL, NULL, NULL)= 1 (in [3])
recv(3, "+OK uasdsaddsasd select"..., 8192, 0) = 1440
select(4, [3], NULL, NULL, NULL)= 1 (in [3])
recv(3, "\r\n  SPAM: so you can recognise o"..., 8192, 0) = 678
select(4, [3], NULL, NULL, NULL)= 1 (in [3])
recv(3, "as an exclamation mark\r\n  SPAM: "..., 8192, 0) = 367

> I'd like to investigate A because one might expect it to be more efficient.
> In the interests of getting this done before we branch, making B happen
> is probably the best option for now.

Socket IO works differently than file IO.  A read() from a
socket returns once data is available, even if it is less
than requested.  In file IO, this case only happens, if you
are at the end of the file.  In socket IO, this will happen all
the time.

The stream_gets function had broken semantics.  It used:

Read data, consume data, repeat.

However, with sockets, you cannot always read more data, even
with blocking (think of an exchange of messages).  The
semantics have been improved to this now:

Consume data, read data, repeat.

This is also more efficient for the average case -- usually,
the buffer will contain more complete lines, so it is faster
to immediately look for a EOL, rather than reading new data
unconditionally.

stream_gets still has the problem that it is not fault
tolerant.  If the underlying stream dies, it will loop
forever.  This needs to be fixed, of course (grep for XXX).

I also added an optional third exit condition to
php_stream_fill_read_buffer.  Previously, it stopped when

- it had read the specified amount of data
- an error occured

Remember that socket IO usually returns less data than
requested.  As such, it must be possible to leave that
function early.  If the stream ops indicate that this third
condition is valid, the function will return after the first
successful read.

- Sascha


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

Re: [PHP-DEV] Re: Fixing socket reads

[Ilia A.]

On October 4, 2002 02:14 pm, Stefan Esser wrote:
> Just wanted to say that I just tested ftp_fopen wrappers
> and whatever was added/modified in the stream code
> since i added ftps_fopen wrapper a few weeks ago
> must have broken it badly. Right now the gets() simply
> blocks... That was not the case a few weeks ago...
>
> Stefan

That is likely to happen for the same reason as http://bugs.php.net/19746,
regardless of the user specified limit the streams code tries to read 8192 
bytes. If the data supplied is over an active stream, such stdin and there is 
no EOF and less then 8192 bytes to data to read, fread() and fgets() will 
block indefinitely.
I have just committed a patch that fixes the problem demonstrated in the above 
mentioned bug report. It is highly likely It'll fix the problem you are 
experiencing as well.

ilia

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

Re: [PHP-DEV] Re: Fixing socket reads

[Zeev Suraski]

At 21:03 04/10/2002, Sascha Schumann wrote:
> Well, my fixes were spurred because my applications broke in
> the deployment phase.  I am extremely surprised by the
> relative low quality of the 4.3 branch.  Many major bugs have
> been lurking in there for months.

Yep, I agree.  I think that the current 4.3 branch is extremely 
unstable.  We're looking at a pretty long release cycle here :I


Zeev


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

Re: [PHP-DEV] Re: Fixing socket reads

[Rasmus Lerdorf]

Yeah, there is a buffering problem right now in the code.

On Fri, 4 Oct 2002, Stefan Esser wrote:

> Just wanted to say that I just tested ftp_fopen wrappers
> and whatever was added/modified in the stream code
> since i added ftps_fopen wrapper a few weeks ago
> must have broken it badly. Right now the gets() simply
> blocks... That was not the case a few weeks ago...
>
> Stefan
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>


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

Re: [PHP-DEV] Re: Fixing socket reads

[Stefan Esser]

Just wanted to say that I just tested ftp_fopen wrappers
and whatever was added/modified in the stream code
since i added ftps_fopen wrapper a few weeks ago
must have broken it badly. Right now the gets() simply
blocks... That was not the case a few weeks ago...

Stefan

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

Re: [PHP-DEV] Re: Fixing socket reads

[Rasmus Lerdorf]

> On Fri, 4 Oct 2002, Rasmus Lerdorf wrote:
>
> > > Guys,
> > >
> > > Are we going to have the streams stuff sorted before tomorrow?
> >
> > I don't think there is anything too magical about Saturday.  The magic was
> > setting a date which has spurred a lot of good fixes.  If we need to give
> > folks a couple more days to finish up stuff then we do that.
>
> Well, my fixes were spurred because my applications broke in
> the deployment phase.  I am extremely surprised by the
> relative low quality of the 4.3 branch.  Many major bugs have
> been lurking in there for months.

Yup, hence the push to get it branched off so we can start fixing this
stuff.

-R


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

Re: [PHP-DEV] Re: Fixing socket reads

[Sascha Schumann]

On Fri, 4 Oct 2002, Rasmus Lerdorf wrote:

> > Guys,
> >
> > Are we going to have the streams stuff sorted before tomorrow?
>
> I don't think there is anything too magical about Saturday.  The magic was
> setting a date which has spurred a lot of good fixes.  If we need to give
> folks a couple more days to finish up stuff then we do that.

Well, my fixes were spurred because my applications broke in
the deployment phase.  I am extremely surprised by the
relative low quality of the 4.3 branch.  Many major bugs have
been lurking in there for months.

- Sascha


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

[PHP-DEV] [RFC] Bug 15209 fix--register_shutdown_function(string function, bool exit)

[Joseph Tate]

Bug 15209 has been open since 24 Jan, 2002.  Simply put, the behavior of
the register_shutdown_function in th 4.0.x series was to close the
connection to the client then run the registered functions.  At the release
of 4.1.0, this behavior was changed, breaking BC, and offering no
alternative functionality, to run the registered functions before closing
the connection with the client.
Since that time my company has been using a patched version of PHP to
develop its product stifling our adoption of later releases of php, even
version 4.2.x releases.  This has in turn reduced my ability to contribute
to the php code base.  It should be noted that a patch to solve the problem
has been in existence since day one.
I propose that we take following action: that we add a second parameter to
the register_shutdown_function named "exit" which allows the user to replace
the functionality once available in 4.0.x (perhaps earlier), since
documented at
http://www.php.net/manual/en/function.register-shutdown-function.php as
"The registered shutdown functions are called after the request has been
completed (including sending any output buffers), so it is not possible to
send output to the browser using echo() or print(), or retrieve the contents
of any output buffers using ob_get_contents()."
and removed from 4.1.x and 4.2.x (which means the documentation is messed
up).  This will allow applications that do a lot of behind the scenes
processing, i.e. graphics rendering or complex data analyses, to be built
using php instead of cgi or some other alternative.  I'll be happy to
provide a patch for this if I can be reasonably sure that it will be
committed.
I hope that this issue can be resolved before the release of 4.3.0.

Joseph Tate


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

Re: [PHP-DEV] Re: Fixing socket reads

[Andrei Zmievski]

On Fri, 04 Oct 2002, Rasmus Lerdorf wrote:
> > Good.
> 
> Not running into anything non-trivial would be bad, wouldn't it?  ;)

non-trivial = difficult
running into difficult = bad
not running into difficult = good

It's Friday and I am hungry. :)

-Andrei   http://www.gravitonic.com/

"The human brain is a wonderful thing. It starts working the moment you
are born, and never stops until you stand up to speak in public. "
 -- Sir George Jessel

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

Re: [PHP-DEV] Re: Fixing socket reads

[Andrei Zmievski]

On Fri, 04 Oct 2002, Rasmus Lerdorf wrote:
> I don't think there is anything too magical about Saturday.  The magic was
> setting a date which has spurred a lot of good fixes.  If we need to give
> folks a couple more days to finish up stuff then we do that.

Right, I was just pushing people a bit. :)

-Andrei   http://www.gravitonic.com/

"Are you implying that cryptic pointer arithmetic isn't just
 as crystal clear as mere simple functions?
 What kind of a C programmer are you?" -- Zeev Suraski

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

Re: [PHP-DEV] Re: Fixing socket reads

[Rasmus Lerdorf]

> > Anyway, I've had to address such issues in PHP 3 already for
> > which I wrote the socket buffering system.  I don't expect to
> > run into anything non-trivial here.
>
> Good.

Not running into anything non-trivial would be bad, wouldn't it?  ;)

-R


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

Re: [PHP-DEV] Re: Fixing socket reads

[Andrei Zmievski]

On Fri, 04 Oct 2002, Sascha Schumann wrote:
> Are there any problems with regard to comitting fixes to that
> branch?

No.

> Anyway, I've had to address such issues in PHP 3 already for
> which I wrote the socket buffering system.  I don't expect to
> run into anything non-trivial here.

Good.

-Andrei   http://www.gravitonic.com/
* If it ain't broken, it doesn't have enough features yet. *

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

Re: [PHP-DEV] Re: Fixing socket reads

[Rasmus Lerdorf]

> Guys,
>
> Are we going to have the streams stuff sorted before tomorrow?

I don't think there is anything too magical about Saturday.  The magic was
setting a date which has spurred a lot of good fixes.  If we need to give
folks a couple more days to finish up stuff then we do that.

-Rasmus


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

[PHP-DEV] Bug handling survey - 80:20 rule

[Gunes Koru]

Hi all contributors of PHP,

As you might have heard, I am conducting a bug handling survey on:

http://www.seas.smu.edu/~gkoru/surveys/dhsurvey.html

So far, we have received answers from the developers, testers, defects
fixers, and project managers in KDE, GNOME, Apache, OpenOffice, Mozilla,
and other projects/sub-projects. Even though, we have not asked any names
or e-mails, some of you have left their contact information and expressed
their willingness for further cooperation in this direction. Thanks for
your interest so far.

If you have not done so, we would appreciate it, if you could fill out
this survey since statistically more and more meaningful interpretations
can be made as your participation increases.  It is a short survey which
consists of three sections that can be filled at once or different
sessions. Many of the questions in the survey were put there purposefully,
and they will make you think about how they apply to PHP project.  You   
will find them very interesting. One more time, this is a research
project,which has many potential implications. This is NOT anything like a
spam, it has no commercial nature and it is aiming to contribute
to PHP just like any other e-mail. We are very "dedicated" to this research,
whose only and only purpose is looking for ways of increasing
the quality of open source products. We apologize in advance if
you receive duplicates of this e-mail.

80:20 rule, which is the subject of this e-mail is a well observed
phenomenon, in many of the large scale software products. These products
were produced by IT, Telecom companies, even by NASA. They were developed
following different methodologies, they were written in different
languages, and the application domain or problems they solve were
different. However, 80:20 rule was still observed. This means that you
might be developing desktop applications, office software, compiler,  
kernel, http server, or whatever, most likely you will make a similar  
observation your project. I included two references at the bottom about
it.  Both of them are very easy to follow and informative. Also, they are
very recent references.

The numbers in 80:20 rule are percentages but not of the same quantity.
80% here represents 80% of the "target risk", which might be defects,  
rework, effort, etc. So, you want to reduce them. 20% represents the 
contributor. You might want to name 20% as modules, component, packages,
for the product if you will. A great deal of your goal in a project lies
in this 80%. And the observations tell us that this 80% target risk stems
from 20% of your modules, or components. If you could only identify this 
20% part in what you develop, you would make substantial improvements in 
quality. The identification techniques could be a subject of another time.
But, now, why is this important? Because, some projects never get to a
desired level of quality, they can not meet their schedule. People code
it, patch it, code it, patch it.. After some time users may loose trust,
it may become something which is not manageable any more. So even though,
the efforts are made by volunteer programmers, it is sad to see that
potential is not used fully. Because these efforts could make even greater
contribution to free software and they could end the software monopoly out
there more quickly.

I am one of those who observes the high amount of traffic in developers
lists. This is huge. Everybody looks at one thing, sees it from a
different point of view, designs are evaluated, code is tested, fixed,
etc. Collaborating, sharing bring many advantages. There is big
potential. I can easily tell that in many cases the communities are much
larger than many software teams in the industry. So, how come the
commercial software can still compete with open source products. One of
the reasons is that they have been applying these techniques for years.
Now think about the advantages of risk identification techniques and the
advantages of open source development combined. Wouldn't it be great? This
is where we see the tremendous opportunity.

As concluding this e-mail, I repeat my invitation one more time. Please
visit:

http://www.seas.smu.edu/~gkoru/surveys/dhsurvey.html

today/this weekend and help us in this research. If you want to see or
remember my previous invitations, they are at the same address. By the
way, if you have already completed it and want to change your answers
(some did ask this issue) please contact me, we need to identify your
unique entry and change it, please do not complete it twice. Thanks for
your support so far. Please contact me for any question you might have.
 
 Gunes

References:

1) Barry Boehm, and Victor R. Basili, "Software defect reduction: Top 10
list", IEEE Computer Magazine, Vol. 34, No.1, pp: 135-137, January 2001.

2) Jeff Tian, "Risk identification techniques for defect reduction and
quality improvement", Software Quality Professional, 2(2):32-41, Mar 2000.
  

--
**

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

[Ilia A.]

The attached patch adds .phps file support for Apache 2, allowing Apache 2 
users to show prettified source of their scripts, just like their Apache 1 
counterparts can.

It is a fairly simple patch, that adds just 2 cmp overhead for this 
functionality, so its not too bad imho. 
Please review the patch and let me know if there are any objections to it's 
addition.

Ilia

Index: sapi_apache2.c
===
RCS file: /repository/php4/sapi/apache2filter/sapi_apache2.c,v
retrieving revision 1.85
diff -u -3 -p -r1.85 sapi_apache2.c
--- sapi_apache2.c	23 Sep 2002 18:51:34 -	1.85
+++ sapi_apache2.c	4 Oct 2002 15:33:46 -
@@ -27,6 +27,7 @@
 #include "SAPI.h"
 
 #include "ext/standard/php_smart_str.h"
+#include "ext/standard/php_standard.h"
 
 #include "apr_strings.h"
 #include "ap_config.h"
@@ -440,12 +441,23 @@ static int php_output_filter(ap_filter_t
 			php_apache_request_ctor(f, ctx TSRMLS_CC);
 
 			apr_file_name_get(&path, ((apr_bucket_file *) b->data)->fd);
-			zfd.type = ZEND_HANDLE_FILENAME;
-			zfd.filename = (char *) path;
-			zfd.free_filename = 0;
-			zfd.opened_path = NULL;
-
-			php_execute_script(&zfd TSRMLS_CC);
+			
+			/* Determine if we need to parse the file or show the source */
+			if (ctx->r->handler[strlen("application/x-httpd-php")] == '\0') {
+zfd.type = ZEND_HANDLE_FILENAME;
+zfd.filename = (char *) path;
+zfd.free_filename = 0;
+zfd.opened_path = NULL;
+
+php_execute_script(&zfd TSRMLS_CC);
+			} else { 
+zend_syntax_highlighter_ini syntax_highlighter_ini;
+
+php_get_highlight_struct(&syntax_highlighter_ini);
+
+ highlight_file((char *)path, &syntax_highlighter_ini TSRMLS_CC);
+			}	
+			
 			php_apache_request_dtor(f TSRMLS_CC);
 			
 			ctx->request_processed = 1;
@@ -560,10 +572,15 @@ static void php_add_filter(request_rec *
 
 static void php_insert_filter(request_rec *r)
 {
-	if (r->content_type &&
-	strcmp(r->content_type, "application/x-httpd-php") == 0) {
-		php_add_filter(r, r->output_filters);
-		php_add_filter(r, r->input_filters);
+	int content_type_len = strlen("application/x-httpd-php");
+
+	if (r->content_type && !strncmp(r->content_type, "application/x-httpd-php", content_type_len-1)) {
+		if (r->content_type[content_type_len] == '\0' || 
+			(r->content_type[content_type_len] == 's' && r->content_type[content_type_len+1] == '\0')) {
+			
+			php_add_filter(r, r->output_filters);
+			php_add_filter(r, r->input_filters);
+		}	
 	}
 }
 



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

Re: [PHP-DEV] [PATCH] String function optimizations

[Jani Taskinen]

On Fri, 4 Oct 2002, Andrei Zmievski wrote:

>> Please let me know if there are any objections, better suggestions, bug 
>> reports (pertaining to this patch) that would need to be resolved before this 
>> bug goes into the CVS.
>
>I am not against merging this in before branching for 4.3.0, but we
>would really need to make sure that these functions are rock solid.
>Hopefully our QA team or what's left of it can come up with some tests.

Propably would be best to wait to get the tests before this
is committed? (sorry if this was obvious..just wanted to be sure..)

--Jani




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

Re: [PHP-DEV] Re: Fixing socket reads

[Sascha Schumann]

> Are we going to have the streams stuff sorted before tomorrow?

Are there any problems with regard to comitting fixes to that
branch?

Anyway, I've had to address such issues in PHP 3 already for
which I wrote the socket buffering system.  I don't expect to
run into anything non-trivial here.

- Sascha


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

Re: [PHP-DEV] Re: Fixing socket reads

[Andrei Zmievski]

On Fri, 04 Oct 2002, Sascha Schumann wrote:
> Here is a second patch, with a third coming some time later.
> 
> The current stream implementation does not consume its
> buffered data before starting new reads.  That causes serious
> problems with sockets, of course, if you have an application
> which exchanges commands/replies with a server.  The
> stream_gets function reads many lines, returns a single one,
> and then tries to read from the network again.
> 
> The patch changes the semantic: Consume the buffer first,
> then call the stream read op.
> 
> My fgets-based pop3 reader works with this patch already.  I
> suspect that fread exposes similar problems though, but I
> don't have time right now to improve it similarly.

Guys,

Are we going to have the streams stuff sorted before tomorrow?

-Andrei   http://www.gravitonic.com/

"The human brain is a wonderful thing. It starts working the moment you
are born, and never stops until you stand up to speak in public. "
 -- Sir George Jessel

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

[PHP-DEV] Re: Fixing socket reads

[Sascha Schumann]

Here is a second patch, with a third coming some time later.

The current stream implementation does not consume its
buffered data before starting new reads.  That causes serious
problems with sockets, of course, if you have an application
which exchanges commands/replies with a server.  The
stream_gets function reads many lines, returns a single one,
and then tries to read from the network again.

The patch changes the semantic: Consume the buffer first,
then call the stream read op.

My fgets-based pop3 reader works with this patch already.  I
suspect that fread exposes similar problems though, but I
don't have time right now to improve it similarly.

- Sascha


Index: network.c
===
RCS file: /repository/php4/main/network.c,v
retrieving revision 1.70
diff -u -r1.70 network.c
--- network.c   28 Sep 2002 22:12:23 -  1.70
+++ network.c   4 Oct 2002 14:38:15 -
@@ -923,7 +923,8 @@
NULL, /* seek */
php_sockop_cast,
php_sockop_stat,
-   php_sockop_set_option
+   php_sockop_set_option,
+   1
 };
 
 
Index: php_streams.h
===
RCS file: /repository/php4/main/php_streams.h,v
retrieving revision 1.51
diff -u -r1.51 php_streams.h
--- php_streams.h   28 Sep 2002 22:10:47 -  1.51
+++ php_streams.h   4 Oct 2002 14:38:16 -
@@ -153,6 +153,7 @@
int (*cast)(php_stream *stream, int castas, void **ret TSRMLS_DC);
int (*stat)(php_stream *stream, php_stream_statbuf *ssb TSRMLS_DC);
int (*set_option)(php_stream *stream, int option, int value, void *ptrparam 
TSRMLS_DC);
+   int dont_block;
 } php_stream_ops;
 
 typedef struct _php_stream_wrapper_ops {
Index: streams.c
===
RCS file: /repository/php4/main/streams.c,v
retrieving revision 1.89
diff -u -r1.89 streams.c
--- streams.c   3 Oct 2002 16:06:41 -   1.89
+++ streams.c   4 Oct 2002 14:38:17 -
@@ -494,7 +494,11 @@

if (justread <= 0)
break;
+   
stream->writepos += justread;
+   
+   if (stream->ops->dont_block)
+   break;
}
 }
 
@@ -615,74 +619,103 @@
return stream->ops->stat(stream, ssb TSRMLS_CC);
 }
 
-PHPAPI char *_php_stream_gets(php_stream *stream, char *buf, size_t maxlen TSRMLS_DC)
+static char *php_stream_locate_eol(php_stream *stream TSRMLS_DC)
 {
+   size_t avail;
char *cr, *lf, *eol = NULL;
-   size_t toread = 0, didread = 0, justread = 0, avail = 0;
char *readptr;

+   readptr = stream->readbuf + stream->readpos;
+   avail = stream->writepos - stream->readpos;
+
+   /* Look for EOL */
+   if (stream->flags & PHP_STREAM_FLAG_DETECT_EOL) {
+   cr = memchr(readptr, '\r', avail);
+   lf = memchr(readptr, '\n', avail);
+
+   if (cr && lf != cr + 1) {
+   /* mac */
+   stream->flags ^= PHP_STREAM_FLAG_DETECT_EOL;
+   stream->flags |= PHP_STREAM_FLAG_EOL_MAC;
+   eol = cr;
+   } else if ((cr && lf && cr == lf - 1) || (lf)) {
+   /* dos or unix endings */
+   stream->flags ^= PHP_STREAM_FLAG_DETECT_EOL;
+   eol = lf;
+   }
+   } else if (stream->flags & PHP_STREAM_FLAG_EOL_MAC) {
+   eol = memchr(readptr, '\r', avail);
+   } else {
+   /* unix (and dos) line endings */
+   eol = memchr(readptr, '\n', avail);
+   }
+
+   return eol;
+}
+
+PHPAPI char *_php_stream_gets(php_stream *stream, char *buf, size_t maxlen TSRMLS_DC)
+{
+   size_t avail = 0;
+   
if (maxlen == 0)
return NULL;
-   
-   while (didread < maxlen - 1) {
-   toread = maxlen - 1;
-   if (toread > stream->chunk_size)
-   toread = stream->chunk_size;
 
-   php_stream_fill_read_buffer(stream, toread TSRMLS_CC);
+   /*
+* If the underlying stream operations block when no new data is readable,
+* we need to take extra precautions.
+*
+* If there is buffered data available, we check for a EOL. If it exists,
+* we pass the data immediately back to the caller. This saves a call
+* to the read implementation and will not block where blocking
+* is not necessary at all.
+*
+* If the stream buffer contains more data than the caller requested,
+* we can also avoid that costly step and simply return that data.
+*/
 
-   readptr

Re: [PHP-DEV] [PATCH] String function optimizations

[Jon Parise]

On Thu, Oct 03, 2002 at 10:21:26PM -0400, Ilia A. wrote:

> After doing a number of tests on PHP's various string functions, I've came up 
> with a patch that significantly improves the performance on those functions.
> The patch optimizes:

If anything, I think it makes the code much more readable, as well.  I
haven't had a chance to apply the patch and test performance, though.

-- 
Jon Parise ([EMAIL PROTECTED]) :: The PHP Project (http://www.php.net/)

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

Re: [PHP-DEV] [PATCH] String function optimizations

[Derick Rethans]

On Fri, 4 Oct 2002, Andrei Zmievski wrote:

> On Thu, 03 Oct 2002, Ilia A. wrote:
> > After doing a number of tests on PHP's various string functions, I've came up 
> > with a patch that significantly improves the performance on those functions.

[...]

> I am not against merging this in before branching for 4.3.0, but we
> would really need to make sure that these functions are rock solid.
> Hopefully our QA team or what's left of it can come up with some tests.

Andrei, bug me every week about those tests please :)

Derick

--

---
 Derick Rethans   http://derickrethans.nl/ 
 JDI Media Solutions
--[ if you hold a unix shell to your ear, do you hear the c? ]-


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

[PHP-DEV] Fixing socket reads

[Sascha Schumann]

The stream system assumes that the callee always wants to
consume *exactly* as much data as the callee is specifying.

This is not the case with sockets where read/recv specify the
*maximum* amount of data to read.

I've verified that PHP 4.3 behaves like earlier versions with
the attached patch.  The current socket-over-streams
implementation fails to work in the default blocking case.

Wez, please let me know what you think about this patch.

- Sascha


? difx
Index: network.c
===
RCS file: /repository/php4/main/network.c,v
retrieving revision 1.70
diff -u -r1.70 network.c
--- network.c   28 Sep 2002 22:12:23 -  1.70
+++ network.c   4 Oct 2002 13:39:36 -
@@ -923,7 +923,8 @@
NULL, /* seek */
php_sockop_cast,
php_sockop_stat,
-   php_sockop_set_option
+   php_sockop_set_option,
+   1
 };
 
 
Index: php_streams.h
===
RCS file: /repository/php4/main/php_streams.h,v
retrieving revision 1.51
diff -u -r1.51 php_streams.h
--- php_streams.h   28 Sep 2002 22:10:47 -  1.51
+++ php_streams.h   4 Oct 2002 13:39:37 -
@@ -153,6 +153,7 @@
int (*cast)(php_stream *stream, int castas, void **ret TSRMLS_DC);
int (*stat)(php_stream *stream, php_stream_statbuf *ssb TSRMLS_DC);
int (*set_option)(php_stream *stream, int option, int value, void *ptrparam 
TSRMLS_DC);
+   int dont_block;
 } php_stream_ops;
 
 typedef struct _php_stream_wrapper_ops {
Index: streams.c
===
RCS file: /repository/php4/main/streams.c,v
retrieving revision 1.89
diff -u -r1.89 streams.c
--- streams.c   3 Oct 2002 16:06:41 -   1.89
+++ streams.c   4 Oct 2002 13:39:38 -
@@ -494,7 +494,11 @@

if (justread <= 0)
break;
+   
stream->writepos += justread;
+   
+   if (stream->ops->dont_block)
+   break;
}
 }
 


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

Re: [PHP-DEV] [PATCH] String function optimizations

[Andrei Zmievski]

On Thu, 03 Oct 2002, Ilia A. wrote:
> After doing a number of tests on PHP's various string functions, I've came up 
> with a patch that significantly improves the performance on those functions.
> The patch optimizes:
>   php_addslashes() - internal PHP function used to add slashes to a string 
>   (15-20% speed increase)
>   php_memnstr() - internal PHP function used to find a multibyte string inside
>   another string. 35-40% speed increase when string is 
>found, 90-100%
>   speed increase when the string is not found.
>   substr_count() - PHP function used to determine the number of times a string
>   occurs within another string. 20-25% speed increase + 
>additional speed
>   gains from usage of optimized php_memnstr() function.
> 
> Please let me know if there are any objections, better suggestions, bug 
> reports (pertaining to this patch) that would need to be resolved before this 
> bug goes into the CVS.

I am not against merging this in before branching for 4.3.0, but we
would really need to make sure that these functions are rock solid.
Hopefully our QA team or what's left of it can come up with some tests.

-Andrei   http://www.gravitonic.com/
* Think digital, act analog. *

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

Re: [PHP-DEV] ZTS and tests problem

[Marcus Börger]

fixed by Sacha - thanks

At 21:05 03.10.2002, Marcus Boerger wrote:
>I do not know why but i get the following error messages when running
>tests:
>
>Warning: Cannot get the virtual filepath of /usr/src/php4-HEAD/pear/PHPDoc
>  in /usr/src/php4-HEAD/run-tests.php on line 160
>/usr/src/php4-HEAD/run-tests.php(160) : Warning - Cannot get the virtual 
>filepath of /usr/src/php4-HEAD/pear/PHPDoc
>
>I tracked i down to filestat.c line 575:
>#ifndef PHP_WIN32
>#ifdef VIRTUAL_DIR
> {
> char *tmpname;
>
> if (virtual_filepath(filename, &tmpname TSRMLS_CC)) {
> php_error(E_WARNING, "Cannot get the virtual 
> filepath of %s\n", filename);
> RETURN_FALSE;
> }
>
> filename = tmpname;
> }
>#endif
>
>But i do not know when it last worked...
>
>Any Help?


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

Re: [PHP-DEV] Re: #19600 [Opn->Csd]: requires full pathname

[Melvyn Sopacua]

At 10:20 4-10-2002, Derick Rethans wrote:

>On Fri, 4 Oct 2002, Melvyn Sopacua wrote:
>
> > Hi,
> >
> > his particular problem may be solved, but that doesn't solve the issue
> > that Windows relative paths don't seem to work.
> >
> > So I'm thinking we should set the base (SablotSetBase not sure about
> > SablotSetSchemeBase) to $_SERVER['PATH_TRANSLATED'] by default, in
> > xslt_create.
> >
> > Any objections or pitfalls I'm missing?
>
>Nope, but it might break some things... but well, I think that it is the
>correct behavior if you change it like that.

According to Petr Gimprich, the stylesheet's URI is used, to resolve relative
paths. "This may be a problem, if the URI is arg:/xslt".

Of course the problem arrises, when XML is passed as a file and XSLT as a
string via args.

Hmm, will test that first.



Met vriendelijke groeten / With kind regards,

Webmaster IDG.nl
Melvyn Sopacua


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

Re: [PHP-DEV] Re: #19600 [Opn->Csd]: requires fullpathname

[Derick Rethans]

On Fri, 4 Oct 2002, Melvyn Sopacua wrote:

> Hi,
> 
> his particular problem may be solved, but that doesn't solve the issue 
> that Windows relative paths don't seem to work. 
> 
> So I'm thinking we should set the base (SablotSetBase not sure about 
> SablotSetSchemeBase) to $_SERVER['PATH_TRANSLATED'] by default, in 
> xslt_create.
> 
> Any objections or pitfalls I'm missing?

Nope, but it might break some things... but well, I think that it is the 
correct behavior if you change it like that.

Derick

--

---
 Derick Rethans   http://derickrethans.nl/ 
 JDI Media Solutions
--[ if you hold a unix shell to your ear, do you hear the c? ]-


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

[PHP-DEV] Re: #19600 [Opn->Csd]: requires full pathname

[Melvyn Sopacua]

Hi,

his particular problem may be solved, but that doesn't solve the issue that Windows 
relative paths don't seem to work.

So I'm thinking we should set the base (SablotSetBase not sure about 
SablotSetSchemeBase) to $_SERVER['PATH_TRANSLATED'] by default, in xslt_create.

Any objections or pitfalls I'm missing?

On 4 Oct 2002 [EMAIL PROTECTED] wrote:

>>> Date: 4 Oct 2002 07:26:07 -
>>> From: [EMAIL PROTECTED]
>>> To: [EMAIL PROTECTED]
>>> Subject: #19600 [Opn->Csd]:  requires full pathname
>>> 
>>>  ID:   19600
>>>  Updated by:   [EMAIL PROTECTED]
>>>  Reported By:  [EMAIL PROTECTED]
>>> -Status:   Open
>>> +Status:   Closed
>>>  Bug Type: XSLT related
>>>  Operating System: Windows XP
>>>  PHP Version:  4.2.3
>>>  New Comment:
>>> 
>>> closing then
>>> 
>>> 
>>> Previous Comments:
>>> 
>>> 
>>> [2002-10-03 19:50:13] [EMAIL PROTECTED]
>>> 
>>> That works, thank you. Problem solved.
>>> 
>>> 
>>> 
>>> [2002-10-03 04:28:57] [EMAIL PROTECTED]
>>> 
>>> Please try http://www.php.net/manual/en/function.xslt-set-base.php to
>>> solve your problem.
>>> 
>>> Regards, Kai
>>> 
>>> 
>>> 
>>> [2002-09-25 13:53:10] [EMAIL PROTECTED]
>>> 
>>> I am using Windows XP, PHP 4.2.3, Apache 1.3.26
>>> 
>>> I am using XSLT to produce HTML output. The code I use is as follows:
>>> 
>>> $arg_buffer = array("/xml" => $xml_string, "/xslt" => $xsl_string);
>>> $result = xslt_process($xp, "arg:/xml", "arg:/xslt", NULL, $arg_buffer,
>>> $params)))
>>> 
>>> My xsl file contains as 'include' statement which points to a file
>>> which exists in the same folder as the PHP script.
>>> 
>>> I initially tried it as  but it
>>> produced this error:
>>> 
>>> 'arg:/pagination.xsl' not found (error code: 65)
>>> 
>>> I then tried it with  and
>>> got this error:
>>> 
>>> cannot open file '/pagination.xsl' (error code: 4)
>>> 
>>> It only works if I enter the full path, as in >> href="file://c:/blah/blah/blah/pagination.xsl"/>
>>> 
>>> It is very inconvenient to have to specify the full pathname in every
>>>  statement. Should it not first look in the current
>>> directory?
>>> 
>>> This may be more of an enhancement request than a bug.
>>> 
>>> 
>>> 
>>> 
>>> 

-- 


Melvyn.


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

RE: [PHP-DEV] PHP Compile errors

[Emanuel Dejanu]

Thanks Markus,

I have succeed to compile the PHP and also my extension.

Best regards,

Emanuel Dejanu

> -Original Message-
> From: Markus Fischer [mailto:[EMAIL PROTECTED]]
> Sent: 3 octombrie 2002 16:57
> To: Emanuel Dejanu
> Cc: [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] PHP Compile errors
> 
> 
> You need to make the include and lib directories from
> http://www.php.net/extra/win32build.zip to be available in
> your MSVC environment.
> 
> On Thu, Oct 03, 2002 at 04:12:38PM +0200, Emanuel Dejanu wrote : 
> > 
> > Hi,
> > 
> > I want to compile PHP 4.2.3 on Windows 2000 but I get
> > the following errors:
> > 
> > php_fopen_wrapper.c
> > ..\main\php_network.h(28) : fatal error C1083: Cannot open 
> include file:
> > 'arpa/inet.h': No such file or directory
> > 
> > 
> > VC++ 6.0 SP5
> > 
> > I get this also with php4-200210030600
> > 
> > Best regards,
> > 
> > Emanuel Dejanu
> > 
> > 
> > -- 
> > PHP Development Mailing List 
> > To unsubscribe, visit: http://www.php.net/unsub.php
> 
> -- 
> GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
>  Derick, while ($xml) $ass->get_new_ideas();
> <[James]> Markus: IE on_user_fart()
> -- People doesn't seem to like the new XHTML2 specs :) --
> 


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