[PHP-DEV] Re: [PHP] JP Graph

[Jason Sheets]

Sounds like a web server configuration problem.  If you are using apache
make sure your httpd.conf is configured to bind to your external IP
address (the default).

Jason
On Thu, 2003-02-27 at 21:17, K wrote:
> Hi all,
> I'm using JPGraph on a localhost for a website opened via a host redirect.
> My problem is that nobody can see the graphs but me ('cause I'm on
> localhost).
> 
> Any clues?
> 
> Thx.
> 
> 
> 
> 
> -- 
> PHP General 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] DLL PHP script for C

[SHEETS,JASON (HP-Boise,ex1)]

Right, it seems like you are looking for sapi/embed,

Take a look at this email
http://www.zend.com/lists/php-dev/200209/msg01063.html

Thanks,
 
Jason Shees, CCNA, MCSE
Exploratory Team Lead

-Original Message-
From: Fernando Serboncini [mailto:[EMAIL PROTECTED]] 
Sent: Thursday, February 06, 2003 8:13 AM
To: [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] DLL PHP script for C

I know that PHP can behave like a "normal" system executable. That's not
what I meant on the previous post.

What I mean is to behave like a scripting language, what means that,
somewhere in my C program I'll be able to run
something like a

executePHP("phpinfo(); $a = 1;");

 function and get back the results inside my C program.

That way, we get a totally editable PHP script being called inside our C
program.

that's what I mean.

[]s
Fernando


"Antony Dovgal" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> On Thu, 6 Feb 2003 12:34:42 -0200
> "Fernando Serboncini" <[EMAIL PROTECTED]> wrote:
>
> > I mean to make possible to PHP behave like a real C scripting language,
like
> What does "real C scripting language" means ?
>
> P.S. take a look at http://gtk.php.net
>
> --
> Wbr,
> Antony Dovgal aka tony2001 mailto:[EMAIL PROTECTED]
> http://phpclub.net
> ---
> Stand for something or you will fall for nothing.



-- 
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] LCC compiler

[Jason T. Greene]

Cool, I will have to try that.

Thanks!!
-Jason

On Fri, 2002-11-15 at 09:11, Andi Gutmans wrote:
> Hey,
> 
> Has anyone managed to get php to compile with lcc? It compiles much faster 
> and therefore is good for development.
> 
> Andi
-- 
Jason T. Greene <[EMAIL PROTECTED]>


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

Re: [PHP-DEV] 64-bit PHP 4.3 (extensive long vs int problems)

[Jason T. Greene]

OK, though I wasn't arguing against your suggestion; I should have
responded to the previous email in the thread. I was just pointing out
that supporting these two may be overkill, but if its being used as a
stop-gap, and since it doesn't really hurt that much, I suppose it
really doesn't matter.

-Jason

On Mon, 2002-11-11 at 10:42, Jason T. Greene wrote:
> Why not just convert to using a long? Is there really a need to have 2
> numeric types in the ini system?
> 
> -Jason
> 
> On Mon, 2002-11-11 at 00:20, Andi Gutmans wrote:
> > Hi,
> > 
> > How about changing the INI_ENTRY macros in debug mode to check if we're 
> > using UpdateInt/UpdateLong and if so check if sizeof(param) == 
> > sizeof(int/long)?
> > This could help a lot.
> > Andi
> > 
> > At 01:12 PM 11/11/2002 +0800, James Devenish wrote:
> > >Hi, just some followup, including some general build problems and some
> > >information about failed tests at the bottom. I have included a set of
> > >patches against 4.3.0pre2 and against CVS HEAD for anyone who's
> > >interested in seeking some form of success with PHP 4.3 on a 64-bit
> > >platform.
> > >
> > >Someone will need to tell me what mailing lists to send to, etc (I am
> > >on php-dev and php-qa to read followups). I'm not sure how to get `make
> > >test` results to you as the script asks 'would you like to send the
> > >report to PHP's QA team' but I say 'n' because I can't send or receive
> > >mail on the machine that I am testing on. I had a few notes about them,
> > >too. << > >over the web. Will use to this sometime>>>
> > >
> > >The `make test` target doesn't work on my test machine (either in the
> > >4.3.0pre2 or when using buildconf) because my $(CC) contains a space
> > >character. So as the target is:
> > >
> > >test: $(SAPI_CLI_PATH)
> > >TEST_PHP_DETAILED
> > > @TEST_PHP_EXECUTABLE=$(top_builddir)/$(SAPI_CLI_PATH) \
> > >  TEST_PHP_SRCDIR=$(top_srcdir) \
> > >  CC=$(CC) \
> > > $(top_builddir)/$(SAPI_CLI_PATH) 
> > > $(top_srcdir)/run-tests.php $(TESTS)
> > >
> > >I change thae second-last line to :
> > >  CC="$(CC)" \
> > >to make it work for me. I don't know how that should be handled in general but
> > >I thought I should point it out.
> > >
> > >Okay, `make test` still not work. Many segfaults in mbstring.
> > >
> > >Also, there seems to be something wrong because there are multiple definitions
> > >of url_adapt_ext, yet only one is used. Also a patch for network.c.
> > >
> > >The attached patches are against 4.3.0pre2, which is what I ran `make test`
> > >with, though I am actually using CVS HEAD with my test web server.
> > >(From a few days ago.)
> > >
> > ><< > >output other than 'Bus error' for a while, it *is* actually testing
> > >correctly. I didn't realise that `make test` only prints test results at
> > >the very end and I had been killing it in the middle of the test because
> > >it "didn't seem to be working">>>
> > >
> > >So, the patch includes: sundry correction of (int size)=(pointer size)
> > >assumptions, introduction of OnUpdateLong, some zend_parse_parameters fixes.
> > >Does not address all instances of sizeof( blah_t ) != sizeof( operand ).
> > >
> > >=
> > >FAILED TEST SUMMARY
> > >-
> > >mb_strtoupper() / mb_strtolower() [ext/mbstring/tests/casefold.phpt]
> > >HTML input/output [ext/mbstring/tests/htmlent.phpt]
> > >mb_convert_encoding() [ext/mbstring/tests/mb_convert_encoding.phpt]
> > >mb_ereg() [ext/mbstring/tests/mb_ereg.phpt]
> > >mb_ereg_search() stuff [ext/mbstring/tests/mb_ereg_search_xxx.phpt]
> > >mb_strlen() [ext/mbstring/tests/mb_strlen.phpt]
> > >
> > >**mbstring: extensive issues with mixed int/pointer.
> > >
> > >Test array_merge and array_walk [ext/standard/tests/array/001.phpt]
> > >Test arsort, asort, krsort, ksort, rsort, and sort 
> > >[ext/standard/tests/array/002.phpt]
> > >Test usort, uksort and uasort [ext/standard/tests/array/003.phpt]
> > >
> > >**array tests: error in the tests: ext/standard/tests/array/data.inc
> > >   

Re: [PHP-DEV] 64-bit PHP 4.3 (extensive long vs int problems)

[Jason T. Greene]

Why not just convert to using a long? Is there really a need to have 2
numeric types in the ini system?

-Jason

On Mon, 2002-11-11 at 00:20, Andi Gutmans wrote:
> Hi,
> 
> How about changing the INI_ENTRY macros in debug mode to check if we're 
> using UpdateInt/UpdateLong and if so check if sizeof(param) == 
> sizeof(int/long)?
> This could help a lot.
> Andi
> 
> At 01:12 PM 11/11/2002 +0800, James Devenish wrote:
> >Hi, just some followup, including some general build problems and some
> >information about failed tests at the bottom. I have included a set of
> >patches against 4.3.0pre2 and against CVS HEAD for anyone who's
> >interested in seeking some form of success with PHP 4.3 on a 64-bit
> >platform.
> >
> >Someone will need to tell me what mailing lists to send to, etc (I am
> >on php-dev and php-qa to read followups). I'm not sure how to get `make
> >test` results to you as the script asks 'would you like to send the
> >report to PHP's QA team' but I say 'n' because I can't send or receive
> >mail on the machine that I am testing on. I had a few notes about them,
> >too. << >over the web. Will use to this sometime>>>
> >
> >The `make test` target doesn't work on my test machine (either in the
> >4.3.0pre2 or when using buildconf) because my $(CC) contains a space
> >character. So as the target is:
> >
> >test: $(SAPI_CLI_PATH)
> >TEST_PHP_DETAILED
> > @TEST_PHP_EXECUTABLE=$(top_builddir)/$(SAPI_CLI_PATH) \
> >  TEST_PHP_SRCDIR=$(top_srcdir) \
> >  CC=$(CC) \
> > $(top_builddir)/$(SAPI_CLI_PATH) 
> > $(top_srcdir)/run-tests.php $(TESTS)
> >
> >I change thae second-last line to :
> >  CC="$(CC)" \
> >to make it work for me. I don't know how that should be handled in general but
> >I thought I should point it out.
> >
> >Okay, `make test` still not work. Many segfaults in mbstring.
> >
> >Also, there seems to be something wrong because there are multiple definitions
> >of url_adapt_ext, yet only one is used. Also a patch for network.c.
> >
> >The attached patches are against 4.3.0pre2, which is what I ran `make test`
> >with, though I am actually using CVS HEAD with my test web server.
> >(From a few days ago.)
> >
> ><< >output other than 'Bus error' for a while, it *is* actually testing
> >correctly. I didn't realise that `make test` only prints test results at
> >the very end and I had been killing it in the middle of the test because
> >it "didn't seem to be working">>>
> >
> >So, the patch includes: sundry correction of (int size)=(pointer size)
> >assumptions, introduction of OnUpdateLong, some zend_parse_parameters fixes.
> >Does not address all instances of sizeof( blah_t ) != sizeof( operand ).
> >
> >=
> >FAILED TEST SUMMARY
> >-
> >mb_strtoupper() / mb_strtolower() [ext/mbstring/tests/casefold.phpt]
> >HTML input/output [ext/mbstring/tests/htmlent.phpt]
> >mb_convert_encoding() [ext/mbstring/tests/mb_convert_encoding.phpt]
> >mb_ereg() [ext/mbstring/tests/mb_ereg.phpt]
> >mb_ereg_search() stuff [ext/mbstring/tests/mb_ereg_search_xxx.phpt]
> >mb_strlen() [ext/mbstring/tests/mb_strlen.phpt]
> >
> >**mbstring: extensive issues with mixed int/pointer.
> >
> >Test array_merge and array_walk [ext/standard/tests/array/001.phpt]
> >Test arsort, asort, krsort, ksort, rsort, and sort 
> >[ext/standard/tests/array/002.phpt]
> >Test usort, uksort and uasort [ext/standard/tests/array/003.phpt]
> >
> >**array tests: error in the tests: ext/standard/tests/array/data.inc
> >   contains "monkey" whereas the test expected results do not. Also, one
> >   test uses pow(2,64) and expects the result to overflow in a 32-bit way.
> >   These problems have been partially fixed in CVS already.
> >
> >var_dump float test [ext/standard/tests/general_functions/008.phpt]
> >overflow check for _php_math_basetozval [ext/standard/tests/math/hexdec.phpt]
> >
> >**var_dump and hexdec: the expected overflows do not occur with 64-bit
> >   operands :)
> >
> >Simple math tests [ext/standard/tests/math/abs.phpt]
> >Simple math tests [ext/standard/tests/math/round.phpt]
> >
> >**maths tests: issues with LONG_MIN and LONG_MAX
> >
> >Various pow() tests [ext/standard/tests/math/pow.phpt]
&g

Re: [PHP-DEV] [PATCH] Proposed modification to log() inext/standard/math.c

[Jason Greene]

I have added the functionality your patch adds, but using a differing
implementation.

Thanks for submitting the feature request and initial patch,

-Jason


On Sun, 2002-11-10 at 16:46, Pollita wrote:
> Apologies... I've made a new .patch file relative to revision 1.93 of
> math.c in the CVS tree with modifications per instructions in
> CODING_STANDARDS.  Hope this meets with approval.
> 
> 
> > On Sun, 10 Nov 2002, Pollita wrote:
> >
> >> I would like to offer the attached minor patch (relative to php-4.2.3)
> >> to ext/standard/math.c to extend the functionality of log() to support
> >> arbitrary bases.
> >
> > Please provide a unified diff (diff -u) against the latest CVS version.
> > Also, please stick to the coding standards as described in the
> > CODING_STANDARDS file.
> >
> > regards,
> > 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 <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
--
Jason Greene <[EMAIL PROTECTED]
 <[EMAIL PROTECTED]>

It is a very humbling experience to make a multimillion-dollar mistake, but it
is also very memorable.  I vividly recall the night we decided how to organize
the actual writing of external specifications for OS/360.  The manager of
architecture, the manager of control program implementation, and I were
threshing out the plan, schedule, and division of responsibilities.

The architecture manager had 10 good men.  He asserted that they could write
the specifications and do it right.  It would take ten months, three more
than the schedule allowed.

The control program manager had 150 men.  He asserted that they could prepare
the specifications, with the architecture team coordinating; it would be 
well-done and practical, and he could do it on schedule.  Futhermore, if
the architecture team did it, his 150 men would sit twiddling their thumbs
for ten months.

To this the architecture manager responded that if I gave the control program
team the responsibility, the result would not in fact be on time, but would
also be three months late, and of much lower quality.  I did, and it was.  He
was right on both counts.  Moreover, the lack of conceptual integrity made
the system far more costly to build and change, and I would estimate that it
added a year to debugging time.
- Frederick Brooks Jr., "The Mythical Man Month" 


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

Re: [PHP-DEV] 64-bit PHP 4.3 (extensive long vs int problems)

[Jason Greene]

I started to work on fixing this problem, but have not had time to
finish my work. I will try to get some time available to work on this
sometime soon.

Thanks,
-Jason

On Sat, 2002-11-09 at 22:25, James Devenish wrote:
> Hi,
> 
> Referring to bug #20268 ("Bus Error on startup"), I have added some
> comments about show-stopping problems with PHP 4.3 with regards to its
> lack of 64-bit cleanliness.  The main problems seem to be Zend's
> OnUpdateInt (which seems misnamed although it uses zend_atoi, it assigns
> to a long) and PHP modules' use of zend_parse_parameters (which again
> acts on longs, not ints, though that has slipped by the authors of some
> modules).  (Please forgive some of the less coherent sentences in my
> comments on the bug.) I have provided patches that demonstrate how I
> managed to get PHP working (in particular with SPARCv9 Solaris 8 and
> Apache 2.0).
> 
> Regards,
> A random but concerned 64-bit user.
> 
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
--
Jason Greene <[EMAIL PROTECTED]
 <[EMAIL PROTECTED]>

The honeymoon is over when he phones to say he'll be late for supper and
she's already left a note that it's in the refrigerator.
-- Bill Lawrence


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

[PHP-DEV] CVS Account Request: jsheets

[Jason Sheets]

I want to contribute to the phpdoc branch as well as help screen defects.

I want to help ensure that examples in the documentation are up to date, write or 
expand on documentation for functions and features without it and work on 
documentation defects in the bug database.

I am a software tester and engineer by trade and lead an Exploratory Testing team, I 
am subscribed to phpdoc, the phpdevel and php-general mailing lists (As  Jason Sheets 
@ HP).

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

RE: [PHP-DEV] Re: Unsigned Problems Revisited

[Jason T. Greene]

Ok,

I hereby volunteer to update the documentation to clearly explain
shifting (with examples).

-Jason


On Wed, 2002-10-30 at 14:05, James Cox wrote:
> We're going to walk into a confusion where people will expect <<< to work
> too, and get bitten. We have to be really careful that we explain it
> properly.
> 
>  -- james
> 
> >
> > I think you guys have convinced me that having >>> only isn't too bad
> > (Jason will kill me now).
> > Does anyone here on php-dev have any additional thoughts?
> > I just want to point out that what convinced me wasn't the "anyone who
> > knows twos complement would know that blah blah blah" argument. Don't
> > forget that most of our PHP users aren't always that knowledgeable and we
> > need to understand and respect that. Anyway, I just wanted to say that
> > because I often get the feeling that people on php-dev forget that it's
> > usually the more computer science oriented people on this list
> > which isn't
> > necessarily the average PHP user.
> >
> > Andi
> >
> > At 11:39 AM 10/29/2002 -0600, Jason T. Greene wrote:
> > >On Thu, 2002-10-24 at 09:51, David M. Lloyd wrote:
> > > > On Thu, 24 Oct 2002, Andi Gutmans wrote:
> > > >
> > > > > At 02:49 PM 10/23/2002 -0500, David M. Lloyd wrote:
> > > > >
> > > > > >The reality of twos-complement, bitwise arithmatic is that
> > there are
> > > > > >three basic shift operations:  shift left, bitwise shift right, and
> > > > > >arithmetic shift right.  This simple fact is one of the
> > basic ideas of
> > > > > >dealing with twos-complement integers.
> > > > >
> > > > > I know that but I still wanted the opposite to be available to keep
> > > > > things symmetrical. I'm not sure but I think CPU's do support both
> > > > > logical and arithmetic shifts and just do the same with
> > both (I might be
> > > > > wrong though).
> > > >
> > > > Generally no, it's a waste of opcode space for modern CISC processors.
> > > > RISC processors often have integrated barrel-shifters, so
> > they don't need
> > > > shift instructions at all.
> > > >
> > > > Intel carries over "arithmetic" shift right instructions from older
> > > > architetures for backwards-compatibility with x86, but their RISC
> > > > implementation (Itanium) does not contain support for the operation.
> > > >
> > > > One RISC example is ARM.  They give you four shift options:
> > Logical left,
> > > > logical right, arithmetic right, and rotate right.  Making
> > the operation
> > > > symmetrical is a waste of precious bit combinations, and
> > would have meant
> > > > either losing another shift operation or else adding another
> > bit to the
> > > > shift operation specifier, which means that another bit would
> > have to be
> > > > sacrificed elsewhere.
> > > >
> > > > Another example is SPARC, which implements shifting with discrete
> > > > instructions, only implents one left shift operator.  PowerPC does not
> > > > implement it either.
> > >
> > >Alpha has 3 instructions as well (log left, log right, arith right)
> > >
> > > > > >Given this fact, there is no reason to have a bogus fourth
> > operator
> > > in the
> > > > > >name of symmetry.  Mathematical operaters are simply not always
> > > > > >symmetrical.  There is no such thing as 'arithmetic shift left' or
> > > > > >'logical shift left' in terms of twos-complement integers,
> > so why invent
> > > > > >it?
> > > > >
> > > > > I agree that they don't *have* to be symmetrical but I think it's
> > > > > better.
> > > >
> > > > Better why?  Anyone who understands twos-complement will
> > understand (and
> > > > expect) the ability to do those three operations, and will not be
> > > > surprised by the lack of two left shifts.  I argue that they
> > *should NOT*
> > > > be symmetrical because it is wrong.
> > >
> > >I have to say I agree, introducing a bogus operator could actually cause
> > >confusion. Java, which has been used several times in past arguments of
> > >"why we should not do XYZ", h

Re: [PHP-DEV] Re: Unsigned Problems Revisited

[Jason T. Greene]

On Wed, 2002-10-30 at 13:26, Andi Gutmans wrote:
> I think you guys have convinced me that having >>> only isn't too bad 

Great, I really think this is the way to go!

> (Jason will kill me now)
/me kills Andi

Just kidding, I am just glad we can come to an agreement, so I can start
working on a patch.

> Does anyone here on php-dev have any additional thoughts?
> I just want to point out that what convinced me wasn't the "anyone who 
> knows twos complement would know that blah blah blah" argument. Don't 
> forget that most of our PHP users aren't always that knowledgeable and we 
> need to understand and respect that. Anyway, I just wanted to say that 
> because I often get the feeling that people on php-dev forget that it's 
> usually the more computer science oriented people on this list which isn't 
> necessarily the average PHP user.

I will keep that in mind.

Thanks,
-Jason

> Andi
> 
> At 11:39 AM 10/29/2002 -0600, Jason T. Greene wrote:
> >On Thu, 2002-10-24 at 09:51, David M. Lloyd wrote:
> > > On Thu, 24 Oct 2002, Andi Gutmans wrote:
> > >
> > > > At 02:49 PM 10/23/2002 -0500, David M. Lloyd wrote:
> > > >
> > > > >The reality of twos-complement, bitwise arithmatic is that there are
> > > > >three basic shift operations:  shift left, bitwise shift right, and
> > > > >arithmetic shift right.  This simple fact is one of the basic ideas of
> > > > >dealing with twos-complement integers.
> > > >
> > > > I know that but I still wanted the opposite to be available to keep
> > > > things symmetrical. I'm not sure but I think CPU's do support both
> > > > logical and arithmetic shifts and just do the same with both (I might be
> > > > wrong though).
> > >
> > > Generally no, it's a waste of opcode space for modern CISC processors.
> > > RISC processors often have integrated barrel-shifters, so they don't need
> > > shift instructions at all.
> > >
> > > Intel carries over "arithmetic" shift right instructions from older
> > > architetures for backwards-compatibility with x86, but their RISC
> > > implementation (Itanium) does not contain support for the operation.
> > >
> > > One RISC example is ARM.  They give you four shift options: Logical left,
> > > logical right, arithmetic right, and rotate right.  Making the operation
> > > symmetrical is a waste of precious bit combinations, and would have meant
> > > either losing another shift operation or else adding another bit to the
> > > shift operation specifier, which means that another bit would have to be
> > > sacrificed elsewhere.
> > >
> > > Another example is SPARC, which implements shifting with discrete
> > > instructions, only implents one left shift operator.  PowerPC does not
> > > implement it either.
> >
> >Alpha has 3 instructions as well (log left, log right, arith right)
> >
> > > > >Given this fact, there is no reason to have a bogus fourth operator 
> > in the
> > > > >name of symmetry.  Mathematical operaters are simply not always
> > > > >symmetrical.  There is no such thing as 'arithmetic shift left' or
> > > > >'logical shift left' in terms of twos-complement integers, so why invent
> > > > >it?
> > > >
> > > > I agree that they don't *have* to be symmetrical but I think it's
> > > > better.
> > >
> > > Better why?  Anyone who understands twos-complement will understand (and
> > > expect) the ability to do those three operations, and will not be
> > > surprised by the lack of two left shifts.  I argue that they *should NOT*
> > > be symmetrical because it is wrong.
> >
> >I have to say I agree, introducing a bogus operator could actually cause
> >confusion. Java, which has been used several times in past arguments of
> >"why we should not do XYZ", has not had a problem with having only the
> >operators that actually exist.
> >
> > > > >Second of all, my understanding of the here-doc operator is that it acts
> > > > >as a unary operation.  I don't see the conflict with the binary
> > > > >application of <<<, given the example of unary and binary -, if it is
> > > > >absolutely neccessary to fulfill the (somewhat psychotic) need for
> > > > >symmetry where it is not realy needed, or even strictly correct.
> > > >
> > > 

Re: [PHP-DEV] Re: Unsigned Problems Revisited

[Jason T. Greene]

On Thu, 2002-10-24 at 09:51, David M. Lloyd wrote:
> On Thu, 24 Oct 2002, Andi Gutmans wrote:
> 
> > At 02:49 PM 10/23/2002 -0500, David M. Lloyd wrote:
> >
> > >The reality of twos-complement, bitwise arithmatic is that there are
> > >three basic shift operations:  shift left, bitwise shift right, and
> > >arithmetic shift right.  This simple fact is one of the basic ideas of
> > >dealing with twos-complement integers.
> >
> > I know that but I still wanted the opposite to be available to keep
> > things symmetrical. I'm not sure but I think CPU's do support both
> > logical and arithmetic shifts and just do the same with both (I might be
> > wrong though).
> 
> Generally no, it's a waste of opcode space for modern CISC processors.
> RISC processors often have integrated barrel-shifters, so they don't need
> shift instructions at all.
> 
> Intel carries over "arithmetic" shift right instructions from older
> architetures for backwards-compatibility with x86, but their RISC
> implementation (Itanium) does not contain support for the operation.
> 
> One RISC example is ARM.  They give you four shift options: Logical left,
> logical right, arithmetic right, and rotate right.  Making the operation
> symmetrical is a waste of precious bit combinations, and would have meant
> either losing another shift operation or else adding another bit to the
> shift operation specifier, which means that another bit would have to be
> sacrificed elsewhere.
> 
> Another example is SPARC, which implements shifting with discrete
> instructions, only implents one left shift operator.  PowerPC does not
> implement it either.

Alpha has 3 instructions as well (log left, log right, arith right)

> > >Given this fact, there is no reason to have a bogus fourth operator in the
> > >name of symmetry.  Mathematical operaters are simply not always
> > >symmetrical.  There is no such thing as 'arithmetic shift left' or
> > >'logical shift left' in terms of twos-complement integers, so why invent
> > >it?
> >
> > I agree that they don't *have* to be symmetrical but I think it's
> > better.
> 
> Better why?  Anyone who understands twos-complement will understand (and
> expect) the ability to do those three operations, and will not be
> surprised by the lack of two left shifts.  I argue that they *should NOT*
> be symmetrical because it is wrong.

I have to say I agree, introducing a bogus operator could actually cause
confusion. Java, which has been used several times in past arguments of
"why we should not do XYZ", has not had a problem with having only the
operators that actually exist.

> > >Second of all, my understanding of the here-doc operator is that it acts
> > >as a unary operation.  I don't see the conflict with the binary
> > >application of <<<, given the example of unary and binary -, if it is
> > >absolutely neccessary to fulfill the (somewhat psychotic) need for
> > >symmetry where it is not realy needed, or even strictly correct.
> >
> > psychotic? Can we please have discussions on a professional and not
> > personal level?
> 
> It is true though, unless you can give me a sound mathematical reason that
> the ops should exist... and saying "it looks right" or "it is easier" is
> not a valid reason, becuase to those with even basic twos-complement math
> background, it looks wrong and is not easier.
> 
> > As far as I remember it does clash with here-docs. I'm pretty sure I
> > thought of an example a while back. I can try and think of one again. In
> > any case, I wouldn't want an overloaded operator. We try and keep away
> > of that kind of stuff with PHP.
Clashing can occur with Constant values, and functions with a \n in
front of the (). 
 
> Very well... then let's not put in the nonsense operator, and just have
> three shift operations: <<, >>, and >>>.

I agree
 
> - D
> 
> <[EMAIL PROTECTED]>
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
-Jason

--
Jason T. Greene <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>




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

Re: [PHP-DEV] pcntl_signal problem

[Jason Greene]

On Fri, 2002-10-25 at 08:50, Edin Kadribasic wrote:
> There were some changes to the pcntl extension. Have a look at
> http://www.zend.com/lists/php-dev/200208/msg00937.html
> 
> Edin
> 
> - Original Message -
> From: "Steve Alberty" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, October 25, 2002 2:35 PM
> Subject: [PHP-DEV] pcntl_signal problem
> 
> 
> >
> > Hi,
> >
> > i've a small problem with the signal handler.
> >
> > These short script demonstrate my problem.

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

Steve, 

Take a look at the ticks section of that email Edin sent you. Signal
callbacks can now only occur if ticks is enabled for either a section of
your code, or if they are globaly enabled.

Steve + Edin + Everyone else,

I will be updating the documentation to explain this before 4.3 is
released, but I wonder If I should have configure spit out a reminder
whenever someone enables pcntl

Any thoughts on that?

Thanks,

-Jason

--
Jason Greene <[EMAIL PROTECTED]
 <[EMAIL PROTECTED]>

Computer programmers never die, they just get lost in the processing.


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

Re: [PHP-DEV] linking php code to html link

[Jason T. Greene]

Alan,

PHP-DEV(Internals) is the list for the development OF the PHP Language
not WITH the PHP language. The PHP-GENERAL list is what you want.

Before emailing this particular question, I would highly suggest you
read the documentation available on PHP's website (http://www.php.net),
and possibly buy a book.

-Jason

--
Jason T. Greene  <[EMAIL PROTECTED]>
 <[EMAIL PROTECTED]>

On Thu, 2002-10-24 at 17:10, Alan Rawkins wrote:
> Hi there,
> 
> I'm wondering if there is a way to attach a php function to an html 
> tag. I basically want to have a button, that when clicked, will execute some
> PHP code.
> 
> Thanks,
> Alan
> 
> 
> 
> -- 
> 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] Unsigned Problems Revisited

[Jason T. Greene]

Before I respond, I just though I would give a summary of how other
languages solve this problem.

-

Perl: Always performs logical unsigned shift, unless "use integer" is in
effect

Java: >>>, >>>=  (they do not have <<<. or <<<=)

C#: Has Signed and Unsigned types

Ruby: Always performs logical unsigned shift, but offers Operator
Overloading, which allows an object to be implemented to perform
arithmetic shifting

Python: Must use long ints (which is bignum)


On Wed, 2002-10-23 at 02:20, Kristian Koehntopp wrote:
> On Tuesday 22 October 2002 19:23, Jason T. Greene wrote:
> > If for some reason we HAVE to have a symmetrical bogus unsigned left
> > shift operator, and we completely disagree with my arguments on
> > overloading the HEREDOC operator, then we can implement >>>>, >>>>=,
> > <<<<. <<<<= as the unsigned shift operators.
> 
> There is no need for operators to be composed from nonalphabetic
> characters. You could use a function (shift is already taken, but
> ashift and ushift for arithmetic shift and unsigned shift are free
> and value, direction and shift width are parameters). Or you could use an 
> operator with a name similar to assembler instructions
> (asl, asr for arithmetic shift left and right, lsl and lsr for logical 
> shift left and right). I rather prefer this to an arbitrary number of
> angle brackets.

There are 2 problems with using alphanumeric characters: 

1. Would require whitespace between identifiers (Fine with me).
2. Assign behavior: would it be lsr= lsl=? or lsra, lsra?

Stig and I had a discussion in irc a few months ago about adding a 'u'
to the operators. It's simple, but looks unique

i.e. u<<, u>>, u<<=, u>>=


> > 2. Shift behavior declare compiler directive
> > 
> >
> > Implement a declare compiler directive which will change the behavior of
> 
> Sucks.
>
Ok that is your opinion, could you elaborate why this 'sucks'?


> > 3. Implement Unsigned Data types
> > -
> 
> This would be a very good idea, but is hard to do in the current
> typing concept of PHP.
> 
I was not referring to adding static typing. It basically boils down to
being able to execute the statement :

$b = (uint) 1 << 2;

The only problem with it is that just like any type in php, it can
easily change. 


> > (Shift function)
> 
> See above, if function, then as generic as possible.
> 
> Kristian
> 



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

[PHP-DEV] [PATCH] 64 bit PHP (long vs int problems)

[Jason Greene]

Hello all, 

After attempting to compile php on solaris as a 64 bit executable, and
resolving the attempt to link libcrack (32bit lib), I was greated with a
nice Bus Error. 

Upon examining the source, it looks like their are alot of areas where
longs and ints are used interchangeably. This is not good since a 64 bit
solaris executable has 64 bit longs, and 32 bit ints.

I have thrown together an initial patch that fixes this, but it does
make make some changes that should be thought about. (such as using a
long instead of an int for memmory limit and size counting) However,
Overall it should not make too big a difference. (especially on the
primarily targetted platforms whose ints and longs are the same)

I did not check anything but the core extensions, so those will need to
be looked at next.

If no one throws any major objects, I will put together a better version
of this patch and commit it upon completion.

Thanks,

-- 
Jason Greene <[EMAIL PROTECTED]>


? log_errors_max_len
? long_errors_max_len=10
? phpt
? longint.patch
Index: Zend/zend_alloc.c
===
RCS file: /repository/Zend/zend_alloc.c,v
retrieving revision 1.105
diff -u -r1.105 zend_alloc.c
--- Zend/zend_alloc.c   18 Aug 2002 21:39:05 -  1.105
+++ Zend/zend_alloc.c   26 Sep 2002 03:41:57 -
@@ -376,7 +376,7 @@
 }
 
 
-ZEND_API int zend_set_memory_limit(unsigned int memory_limit)
+ZEND_API long zend_set_memory_limit(unsigned long memory_limit)
 {
 #if MEMORY_LIMIT
TSRMLS_FETCH();
Index: Zend/zend_alloc.h
===
RCS file: /repository/Zend/zend_alloc.h,v
retrieving revision 1.39
diff -u -r1.39 zend_alloc.h
--- Zend/zend_alloc.h   18 Aug 2002 21:39:05 -  1.39
+++ Zend/zend_alloc.h   26 Sep 2002 03:41:57 -
@@ -108,7 +108,7 @@
 #define safe_estrdup(ptr)  ((ptr)?(estrdup(ptr)):(empty_string))
 #define safe_estrndup(ptr, len) ((ptr)?(estrndup((ptr), (len))):(empty_string))
 
-ZEND_API int zend_set_memory_limit(unsigned int memory_limit);
+ZEND_API long zend_set_memory_limit(unsigned long memory_limit);
 
 ZEND_API void start_memory_manager(TSRMLS_D);
 ZEND_API void shutdown_memory_manager(int silent, int clean_cache TSRMLS_DC);
Index: Zend/zend_globals.h
===
RCS file: /repository/Zend/zend_globals.h,v
retrieving revision 1.91
diff -u -r1.91 zend_globals.h
--- Zend/zend_globals.h 23 Sep 2002 12:00:38 -  1.91
+++ Zend/zend_globals.h 26 Sep 2002 03:41:57 -
@@ -227,9 +227,9 @@
int fast_cache_stats[MAX_FAST_CACHE_TYPES][2];
 #endif
 #if MEMORY_LIMIT
-   unsigned int memory_limit;
-   unsigned int allocated_memory;
-   unsigned int allocated_memory_peak;
+   unsigned long memory_limit;
+   unsigned long allocated_memory;
+   unsigned long allocated_memory_peak;
unsigned char memory_exhausted;
 #endif
 };
Index: Zend/zend_ini.c
===
RCS file: /repository/Zend/zend_ini.c,v
retrieving revision 1.23
diff -u -r1.23 zend_ini.c
--- Zend/zend_ini.c 23 Sep 2002 12:00:39 -  1.23
+++ Zend/zend_ini.c 26 Sep 2002 03:41:57 -
@@ -436,12 +436,12 @@
 #else
char *base;
 
-   base = (char *) ts_resource(*((int *) mh_arg2));
+   base = (char *) ts_resource(*((long *) mh_arg2));
 #endif
 
p = (long *) (base+(size_t) mh_arg1);
 
-   *p = zend_atoi(new_value, new_value_length);
+   *p = zend_atol(new_value, new_value_length);
return SUCCESS;
 }
 
Index: Zend/zend_operators.c
===
RCS file: /repository/Zend/zend_operators.c,v
retrieving revision 1.124
diff -u -r1.124 zend_operators.c
--- Zend/zend_operators.c   31 Aug 2002 20:53:48 -  1.124
+++ Zend/zend_operators.c   26 Sep 2002 03:41:57 -
@@ -36,9 +36,9 @@
 #include "ext/bcmath/number.h"
 #endif
 
-ZEND_API int zend_atoi(const char *str, int str_len)
+ZEND_API long zend_atol(const char *str, int str_len)
 {
-   int retval;
+   long retval;
 
if (!str_len) {
str_len = strlen(str);
Index: Zend/zend_operators.h
===
RCS file: /repository/Zend/zend_operators.h,v
retrieving revision 1.51
diff -u -r1.51 zend_operators.h
--- Zend/zend_operators.h   30 Apr 2002 14:47:29 -  1.51
+++ Zend/zend_operators.h   26 Sep 2002 03:41:57 -
@@ -183,7 +183,7 @@
 ZEND_API void zend_compare_arrays(zval *result, zval *a1, zval *a2 TSRMLS_DC);
 ZEND_API void zend_compare_objects(zval *result, zval *o1, zval *o2 TSRMLS_DC);
 
-ZEND_API int zend_atoi(const char *str, int str_len);
+ZEND_API long zend_atol(const char *str, int str_len);
 
 #define convert_to_ex_master(ppzv, lower_type, upper_type) \
if ((*ppzv)->ty

Re: [PHP-DEV] Binary Safety, Sockets and Raw sockets

[Jason T. Greene]

On Sat, 2002-09-21 at 00:21, Hans Zaunere wrote:
> 
> 4.2.3 on FreeBSD 4.6.2  (--enable-cli,--enable-sockets,etc)
> 
> I've been taking a look at the socket_* functions in PHP, and
> specifically using raw sockets.  I've started out with ICMP, and I can
> form the ICMP header (more or less) and send it out with an
> insufficient TTL; and as expected I get a ICMP 11 (Time Exceeded)
> response from an enroute gateway.  However, when I set a proper TTL
> (32, for example) I see the packet arrive at the remote host, however
> it is apparently dropped.
> 
> So a couple things have come up:
> 
> -- I'm guessing that the socket_* functions, except socket_read() and
> socket_write(), are not binary safe?

socket_read() and socket_write() are binary safe, but there was a binary
safety issue in socket_recvfrom that is fixed in CVS

> -- While it seems the STREAM and DGRAM sockets work as expected for the
> most part, what about RAW sockets?  I find that the underlying
> functions work fine to create the socket, etc, however I'm having a
> hard time working with the binary data in PHP.  For instance, creating
> the header and then reading it seems tortuous.  Any hints/remedies for
> this?  I think sockets, and especially raw, could be very handy in PHP,
> and would like to know how/if this functionality will be expanded (hey,
> the world needs another traceroute/ping program right?).  I was on my
> way to writing this in PHP, but have fell on hard times with binary
> manipulation.
> 

The best way to do this kind of thing is to use the pack/unpack
functions. _HOWEVER_, php internally treats all numbers as signed
values. Which will make what you are doing almost impossible. pack could
be modified to correct this, but it could be lost if you did something
like a right shift on the value. (PHP currently only supports an
arithmetic right shift).

> -- Another problem I've run into, and again concerning binary
> manipulation, is forming the correct Internet Checksum (rfc1071).  I'm
> not the handiest with bit tricks, but I tried to model the in_cksum()
> function and just couldn't get very far.  Any ideas/tips on this?

This is most likely because of the right shift problem I mentioned
above. However, it would probably be better to just make a php function
which performs an internet checksum.

 
> A clean, but at the same time low-level/raw socket interface I think
> would be extremely useful and I'd like to help in any way I can.

To be honest, I haven't spent much time on making sure that all the
functionality with RAW sockets is there. However, not considering signed
issues, pack/unpack, /ext/sockets, and that checksum function should
give you the functionality you need.

If you notice any issues with the sockets extension in this area, email
me and I will fix them. Also, if you have come up with, or are planning
on making patches in this area, I would gladly accept them : )

Thanks,

-Jason



 
> Thanks!
> 
> Hans
> 
> 
> 
> 
> 
> 
> __
> Do you Yahoo!?
> New DSL Internet Access from SBC & Yahoo!
> http://sbc.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: sockets extension...pecl it

[Jason T. Greene]

What I was saying in my earlier email much longer drawn out email was,
that the API changes have been really final since version 4.2.0. The
only reason I would change it, would be if someone demonstrated a
problem with the interface, which no one has for 4.2.0 - 4.2.3 versions.
The only API changes that could possibly occur in the future would be
the vector functions, and (of course) there could always be the addition
of more functions.

Most of the other work needed to mark the extension stable has been
done, all that remains is that I have some small win32 work left to do.

The biggest thing I would like to have complete *by 4.3* is good solid
docs on this extension (There is some already done). I am planning on
working on this, and I have had one volunteer to help out.

If you are really interested in helping out, there are multiple options:
* send examples
* help out with docs
* send patches
* open bug reports
* close bug reports : )

Thanks,

-Jason


On Wed, 2002-09-11 at 17:34, Brian Lalor wrote:
> Jason Greene <[EMAIL PROTECTED]> writes:
> 
> > This extension does not belongs in PECL. It is fully platform
> > compatible, all other languages offer this functionality, it is actively
> > maintained (by me), and it will be marked stable by version 4.3
> 
> Jason, can you help me understand what needs to be done to make this extension
> non-experimental for the next release of PHP?  Can we at least finalize the
> API so that *I* can work on a migration path for my own work?
> 
> What help do you need?
> 
> -- 
> Brian Lalor
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> (v) 480-333-3196
> (f) 480-760-9298
> 
> 
> 
> -- 
> 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: sockets extension

[Jason Greene]

First of all, If you have actually been having problems with this
extension, all you need to do is open a bug report and/or email this
list, and I would have been happy to take a look at fixing any possible
issue. 

Now, to answer your question about why the api has undergone 3 changes: 


This is because the original version  of the extension that was
contributed was very platform specific, and the developer who wrote did
not have too much time to maintain it. Afterwords, Sterling did a lot of
the maintenance and enhancement work on it, but he is very busy working
on other areas of php. Daniel Beulshausen then came in and wrote the
win32 port, and changed the api quite a bit. He also started the task of
it following php extension standards (i.e. namespacing the function
names). After fixing a few bugs, I noticed that this extension needed a
lot of work to make it rock solid. 

I then emailed the list with a plan to enhance and fix several aspects
of this extension, as well as requesting feedback from all users of the
extension. *i got _VERY_ few responses*. Although, those that I did get
responses from did provide good feedback and suggestions. 

I announced in my mailing that all API changes would be finalized in
version 4.2.X, and that if all issues were resolved by 4.3, then the
extension would be no longer marked experimental. 

http://marc.theaimsgroup.com/?l=php-dev&m=101554464018314&w=2

We are proceeding along quite as planned. I have committed myself as the
extension's MAINTAINER, and I am still planning to mark it as stable by
4.3..The one exception is that I will most likely mark the vector
functions experimental, as their are still some issues with them, and I
am not sure about their current implementation. One area that I have
been really hoping on focusing on before 4.3 is getting some good solid
docs that reflect how to use this extension. (Sorry they haven't come
sooner, I have just been so busy lately) 


I do greatly plan on keeping this extension production quality, as I use
it in a 24x7 environment. 

If you are equally committed to having a solid sockets extension in php,
then you are more then welcome to help out. 

Thanks, 
-Jason <[EMAIL PROTECTED]> 



> --
>   Brian Lalor |http://introducingthelalors.org/
>   [EMAIL PROTECTED] (email)  |  [EMAIL PROTECTED] (jabber)
>N33°27.369' W111°56.

304' (Earth)
> 
> 
> 
> -- 
> 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] sockets extension...pecl it

[Jason Greene]

This extension does not belongs in PECL. It is fully platform
compatible, all other languages offer this functionality, it is actively
maintained (by me), and it will be marked stable by version 4.3

-Jason


n Mon, 2002-09-09 at 18:13, Shane Caraveo wrote:
> Dan Kalowsky wrote:
> > Because the user can see how active such functionality is by looking at
> > the CVS logs, and doing a search on php-dev conversations.
> 
> Sorry, but that's a copout.  It expects way to much of the user.  If 
> it's going to remain experimental, OR the api is going to continue to 
> change in incompatible ways, it shouldn't be part of the standard PHP 
> distribution.  We have a means to distribute extensions outside of PHP 
> now, IMO experimental extensions should not be allowed into the core PHP 
> distribuation any longer.  PECL it.
> 
> Shane
> 
> 
> 
> -- 
> 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] multiple keyword text box

[Jason]

Hi,
What is the necessary code to return a recordset from a single text box with
more than one keyword in it (like most search engines do)?
Thanks



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

Re: [PHP-DEV] socket_recvfrom

[Jason Greene]

On Tue, 2002-08-27 at 10:23, Torsten Schlabach wrote:
> Hi!
> 
> I am not sure if I
> a) misunderstood what the function is good for
> b) found a documentation problem or
> c) found a bug.
> 
> Maybe one of the more senior people on that list can advise me wether I
> should file a bug report or not.
> 
> I am writing some code in PHP that makes use of the socket_ functions and
> UDP communication. It is my understanding that the function socket_recvfrom()
> is supposed to read from the socket up to as many bytes as I tell it, store
> them in a buffer and fill in two variables that tell me from what address:port
> the packet that I just read actually came from.
> 
> Am I right with that?


yep

> 
> If so: Everything seems fine for me except that the buffer is always empty
> though the functions reports to me that it read n bytes. The other thing that
> scares me is that I can (or should I say: have to) issue an additional
> socket_read to read the same packet again; this time my buffer being filles.

I just took a look and it appears that socket_recvfrom is not binary
safe. I bet this is the problem you are seeing. Is this binary data you
are transmitting?

I will have commit binary safety for the fix shortly

-Jason

> 
> In fact I could leave out the socket_recvfrom() and just call socket_read,
> but that way I do not get to know the address:port of the sender.
> 
> But I don't think it is meant to be use that way (calling both functions one
> after the other) to get one packet, is it?
> 
> Any thoughts are welcome.
> 
> Regards,
> Torsten
> 
> 
> -- 
> 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] objects as string and arrays as string

[Jason T. Greene]

stratification = stringification
(damn spellchecker)

On Fri, 2002-08-16 at 09:30, Jason T. Greene wrote:
> Perl has this (it's called "stratification"), and it is quite useful.
> One example is that you have an error object that contains various
> properties (line location, error class, error level, error code, etc).
> And on evaluating the object as a string, it dumps it as an easy to read
> error message.
> 
> -Jason
> 
> 
> 
> On Fri, 2002-08-16 at 08:52, Brad LaFountain wrote:
> > I want to throw together a quick hack so that objects can implement a
> > __as_string() method that will get called when the string is used in a string
> > contex. Instead of append "Object".
> > 
> > $s = (string)$object;
> >  or
> > $s .= $object;
> > 
> > also the same things with arrays that will do something similar to
> > $s = implode(" ", $array);
> > 
> > $s = (string)$array;
> > $s = $array . "\n";
> > 
> > Before anyone jumps on this and says no way cause it easy to implemnt your own
> > __to_string() and call it when you want it or what is wrong with implode(" ",
> > $array). Think of exactly how usefull is appending the word "Array" or
> > "Object".
> > 
> >  Thoughts?
> > 
> >  - brad
> > 
> > __
> > Do You Yahoo!?
> > HotJobs - Search Thousands of New Jobs
> > http://www.hotjobs.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
> 



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

Re: [PHP-DEV] objects as string and arrays as string

[Jason T. Greene]

Perl has this (it's called "stratification"), and it is quite useful.
One example is that you have an error object that contains various
properties (line location, error class, error level, error code, etc).
And on evaluating the object as a string, it dumps it as an easy to read
error message.

-Jason



On Fri, 2002-08-16 at 08:52, Brad LaFountain wrote:
> I want to throw together a quick hack so that objects can implement a
> __as_string() method that will get called when the string is used in a string
> contex. Instead of append "Object".
> 
> $s = (string)$object;
>  or
> $s .= $object;
> 
> also the same things with arrays that will do something similar to
> $s = implode(" ", $array);
> 
> $s = (string)$array;
> $s = $array . "\n";
> 
> Before anyone jumps on this and says no way cause it easy to implemnt your own
> __to_string() and call it when you want it or what is wrong with implode(" ",
> $array). Think of exactly how usefull is appending the word "Array" or
> "Object".
> 
>  Thoughts?
> 
>  - brad
> 
> __
> Do You Yahoo!?
> HotJobs - Search Thousands of New Jobs
> http://www.hotjobs.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] Build warnings on OSX in sockets

[Jason T. Greene]

All of the warning messages you list, with the exception of the last, is
specific to the readmsg() sendmsg() code which uses msghdr's (A messgae
header has all void * members).  They should not cause any problems, but
I will clean them up.

The last message is referring to a buffer that is used in the case that
you are running windows, or your platform does not support hsterror(). I
can clean that up as well

-Jason



On Thu, 2002-08-15 at 10:37, Dan Kalowsky wrote:
> Haven't noticed this before, so I'm guessing this isn't a good thing.
> 
> /Users/dank/Development/php4-cvs/ext/sockets/sockets.c: In function
> `zif_socket_recvmsg'
> /Users/dank/Development/php4-cvs/ext/sockets/sockets.c:1524: warning:
> assignment from incompatible pointer type
> /Users/dank/Development/php4-cvs/ext/sockets/sockets.c:1529: warning:
> assignment from incompatible pointer type
> /Users/dank/Development/php4-cvs/ext/sockets/sockets.c:1578: warning:
> assignment from incompatible pointer type
> /Users/dank/Development/php4-cvs/ext/sockets/sockets.c:1584: warning:
> assignment from incompatible pointer type
> /Users/dank/Development/php4-cvs/ext/sockets/sockets.c: In function
> `zif_socket_sendmsg':
> /Users/dank/Development/php4-cvs/ext/sockets/sockets.c:1670: warning:
> assignment from incompatible pointer type
> /Users/dank/Development/php4-cvs/ext/sockets/sockets.c:1698: warning:
> assignment from incompatible pointer type
> /Users/dank/Development/php4-cvs/ext/sockets/sockets.c: At top level:
> /Users/dank/Development/php4-cvs/ext/sockets/sockets.c:115: warning:
> `php_strerror_buf' defined but not used
> 
> >---<
> Dan Kalowsky  "A little less conversation,
> http://www.deadmime.org/~dank  a little more action."
> [EMAIL PROTECTED]  - "A Little Less Conversation",
> [EMAIL PROTECTED]  Elvis Presley
> 
> 
> 
> -- 
> 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] pcntl - class callbacks // dio ASYNC

[Jason T. Greene]

Ok, I will take a look at that. Thanks for the patch, class callbacks 
were actually on my todo list. I just haven't had much time to work on
php lately, but I will work on merging it with the following features:

ticks back-end replacement
system call interruption ability

-Jason


On Mon, 2002-08-12 at 08:38, Alan Knowles wrote:
> Jason T. Greene wrote:
> 
> >Doesn't this currently work without your patch?
> >
> it does if we add O_ASYNC to the defines in dio
> 
> the pcntl patch just fixes class based callbacks.. *the memory leaks I 
> mentioned earlier where due to creating the signal connections before 
> forking. - works OK if you connect the signals after forking.
> 
> regards
> alan
> 
> 
> >
> >-Jason
> >
> >
> >On Thu, 2002-08-08 at 02:49, Alan Knowles wrote:
> >  
> >
> >>this efree needs removing..
> >>
> >>
> >>
> >>>
> >>>+
> >>>+efree(*call_name); 
> >>>+DEBUG_OUT("done call_user function\n");
> >>>+/*call_user_function(EG(function_table), NULL, call_name, 
>&retval, 1, ¶m TSRMLS_CC); */
> >>>   }
> >>> 
> >>>
> >>>  
> >>>
> >>I can now use the dio with ASYNC like this..
> >>
> >> >>
> >>dl('dio.so');
> >>
> >> 
> >>/* signal callbacks
> >>
> >>*/
> >> 
> >>function got_data() {
> >>global $fd;
> >>$data = dio_read($fd,256);
> >>   
> >>if ($data) {
> >>echo $data;
> >>}
> >>
> >>}
> >>
> >>$fd = dio_open('/dev/ttyS0', O_RDWR | O_NOCTTY | O_NONBLOCK);
> >>
> >>dio_fcntl($fd,F_SETOWN,posix_getpid());
> >>dio_fcntl($fd,F_SETFL, O_ASYNC );
> >>//dio_fcntl($fd,F_SETFL, O_SYNC );
> >>pcntl_signal(SIGIO, 'got_data');
> >>
> >>dio_tcsetattr($fd, array(
> >>'baud' => 9600,
> >>'bits' => 8,
> >>'stop'  =>1,
> >>'parity' => 0
> >>));
> >>echo "STARTING READ";
> >>while (1) {
> >>   usleep(1)
> >>}
> >> 
> >>?>
> >>
> >>
> >>
> >> 
> >>
> >>
> >>
> >
> >
> >  
> >
> 
> 
> 



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

Re: [PHP-DEV] pcntl - class callbacks // dio ASYNC

[Jason T. Greene]

Doesn't this currently work without your patch?

-Jason


On Thu, 2002-08-08 at 02:49, Alan Knowles wrote:
> 
> this efree needs removing..
> 
> >  
> >+
> >+efree(*call_name); 
> >+DEBUG_OUT("done call_user function\n");
> >+/*call_user_function(EG(function_table), NULL, call_name, &retval, 
>1, ¶m TSRMLS_CC); */
> > }
> >  
> >
> 
> I can now use the dio with ASYNC like this..
> 
>  
> dl('dio.so');
> 
>  
> /* signal callbacks
> 
> */
>  
> function got_data() {
> global $fd;
> $data = dio_read($fd,256);
>
> if ($data) {
> echo $data;
> }
> 
> }
> 
> $fd = dio_open('/dev/ttyS0', O_RDWR | O_NOCTTY | O_NONBLOCK);
> 
> dio_fcntl($fd,F_SETOWN,posix_getpid());
> dio_fcntl($fd,F_SETFL, O_ASYNC );
> //dio_fcntl($fd,F_SETFL, O_SYNC );
> pcntl_signal(SIGIO, 'got_data');
> 
> dio_tcsetattr($fd, array(
> 'baud' => 9600,
> 'bits' => 8,
> 'stop'  =>1,
> 'parity' => 0
> ));
> echo "STARTING READ";
> while (1) {
>usleep(1)
> }
>  
> ?>
> 
> 
> 
>  
> 



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

Re: [PHP-DEV] Implementing Threading: Some Hints (Was Re: [PHP-DEV]phpthreads - hints anyone...)

[Jason T. Greene]

> To make threading useful, you would need to somehow arrange for multiple
> threads to access the same underlying zval data without blocking all
> the threads.  This just isn't possible AFAIK.

Yes, this is definitely not possible without greatly modifying the
engine's zval management (which would introduce tons of locks which
would kill performance)


> If you want fast read-only access to "shared" zvals, you can serialize
> (just like sessions) the zval from the main thread and unserialize it
> into your new thread.  This isn't strictly read-only, although writes
> will only be visible to the new thread.  The advantage is that since
> the zval lives in the threads own engine/address-space, no
> thread-serialization occurs so performance is "better".

Automatically serializing is a good idea, though I think the performance
loss would out way the benefits.

IMO, the main difficulty is having the language automatically handle
reads and writes to any value in any thread. The functionality gained
from this automation is minimal. If the programmer is required to use a
single structure to share data between threads, then it forces them to
really think about the IPC between threads. Plus, we get the added
benefit of being able to optimize that bridge for the best possible
performance.

IMO an overloaded object that abstracted a special shared memory
structure with read/write locking per member is the way to go.

Simple scalar values could be implemented as direct copying, and complex
structures (arrays, objects) could use serialization.

-Jason


> 
> --Wez.
> 
> 
> 
> 
> 
> -- 
> 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] phpthreads - hints anyone...

[Jason T. Greene]

On Thu, 2002-08-01 at 04:43, Alan Knowles wrote:
> >
> > It's not about looking at the perl code, that will tell you nothing 
> > unless you know perl internals.  It's about the way the interpreter 
> > works, some of the architecture, that is simular to PHP.  In PHP, 
> > threads are isolated, kind of like seperate processes, but in threads.
> 
> 
>  From my understanding they are 'forced to be isolated' by the TSRM 
> stuff.  which looks like it stores globals in something like an 
> associated array ( thread id => global c variable - eg. compiler_globals 
> etc.), when ZTS is enabled..
> 
> > Everything in PHP works that way, so in creating threads for php 
> > scripts, you have to have a seperate interpreter.  Then you have to 
> > create a "bridge" between the threads for shared variables.  shmop 
> > comes close to what is needed, but not close enough.
> 
> the real use of the threading I guess is for people who want to write 
> tcp servers, or desktop gtk apps.
> 
> Thoughts on accessing 'threaded shared vars'
> 
> $_THREADVAR['gtktext'] type..
> 
> php_threads_malloc_lock();
> $_THREADVAR['gtktext']->add_text('some data ouput');
> php_threads_malloc_unlock();
> 
> this would I guess involve rather heavy changes to the ZE engine to 
> recogize an lock/unlock, copy (rather than refcount) etc. variables that 
> where threaded..
> 
> 
> Threaded objects???

Yes, if you created an overloaded object that handled the sharing of
data there would be no need to modify the engine. Instead of using
methods, you could also use property offsets.

Since an overloaded object is given both read and write hooks, you 
can improve performance by having both shared(read) and exclusive(write)
locks. These locks could even be on a per property basis.


> I guess the other consideration is to have thread variable objects..
> $threadvar  = new Thread_Var();
> $threadvar->setNewObject('mywidget','GtkWindow');
> $threadvar->set('mywidget',$gtkobject);
> $var = $threadvar->get('mywidget');
> $var = $threadvar->getArray('key','val');
> $threadvar->callMethod('mywidget', 'add_text','something');
> 
> obviously copying and accessing these would probably be easier to cope 
> with ( without having to modify heavily the zend engine) -  we could do 
> 'real' copying on the data, rather than refcounting them. and reduce the 
> headaches...
> 
> > You're much closer to what needs to happen now.  But you cannot simply 
> > point to the memory for another thread.  Doing that will cause 
> > problems like you are running into.  You actually have to copy a bunch 
> > of stuff so each thread is completely independent.
> 
> Do you mean we will have to really physically copy the all theopcode 
> data from one thread to another?

Yes, since there are multiple interpreters, they must be synchronized.
(This way they are all allowed to access the POST GET SERVER vars) 


-Jason



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

Re: [PHP-DEV] phpthreads - hints anyone...

[Jason T. Greene]

On Thu, 2002-08-01 at 08:04, [EMAIL PROTECTED] wrote:
> On 31 Jul 2002, Jason T. Greene wrote:
> 
> > Instead of mutexing the entire interpreter to death, why don't you try
> > creating multiple interpreters (each in a thread), and then come up with
> > a sharing mechanism.
> 
> Sounds like duplication some other thing :)
> 
> Derick

parse error on line 1 : )
huh?


-Jason
> 
> > On Wed, 2002-07-31 at 03:57, Alan Knowles wrote:
> > > Im looking at adding threading to php, (for the cgi/cli stuff)..
> > > 
> > > The story so far:
> > > 
> > > I've created an extension which diverts all zend_execute calls into the 
> > > extension -> phpthreads_execute.
> > > this function is a copy of zend_execute with a few modifications
> > > - to copy & restore things like  EG(active_symbol_table);
> > > - to malloc lock and unlock the execute loop and release on each opcode.
> > > 
> > > I've started testing the phpthreads_create($callback); - it appears to 
> > > work ok, execept it segfaults on completion.. - trying to reduce 
> > > refcounts somewhere.
> > > 
> > > The fireup code looks something like this..
> > > 
> > > void phpthreads_create(void *ptr) {
> > > zval myretval;
> > > zval *callback = (zval *) ptr;
> > >   
> > > if (!call_user_function( EG(function_table), NULL, callback, 
> > > &myretval, 0, NULL TSRMLS_CC ))  {
> > > zend_error(E_ERROR, "Problem Starting thread with 
> > > callback");
> > > }
> > >
> > > pthread_exit(NULL);
> > >
> > >
> > > }
> > > /* {{{ proto string phpthreads_thread(string function)
> > >Return a string to confirm that the module is compiled in */
> > > PHP_FUNCTION(phpthreads_create)
> > > {
> > >  
> > > zval *callback;
> > > pthread_t thread;
> > >
> > >   if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "z", 
> > > &callback) == FAILURE) {
> > >   return;
> > >   }
> > > pthread_create( &thread, NULL, (void *) phpthreads_create, 
> > > (void*) callback);
> > > RETURN_TRUE;
> > > }
> > > 
> > > and the backtrace of the simple threaded test looks like this..
> > > 0x08128f08 in _zval_ptr_dtor (zval_ptr=0x81b5ce8) at 
> > > /usr/src/php/php4/Zend/zend_execute_API.c:275
> > > 275 (*zval_ptr)->refcount--;
> > > (gdb) bt
> > > #0  0x08128f08 in _zval_ptr_dtor (zval_ptr=0x81b5ce8) at 
> > > /usr/src/php/php4/Zend/zend_execute_API.c:275
> > > #1  0x424ceba2 in ?? ()
> > > #2  0x424c7c92 in ?? ()
> > > #3  0x08130588 in zend_execute_scripts (type=8, retval=0x0, 
> > > file_count=3) at /usr/src/php/php4/Zend/zend.c:810
> > > #4  0x08110abd in php_execute_script (primary_file=0x40006c71) at 
> > > /usr/src/php/php4/main/main.c:1398
> > > #5  0x08110138 in php_module_shutdown () at 
> > > /usr/src/php/php4/main/main.c:1058
> > > #6  0x2e325f43 in ?? ()
> > > 
> > > does anyone want to suggest what might be missing - is it worth putting 
> > > this into pecl - and does someone what to lend a hand??
> > > 
> > > regards
> > > alan
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > -- 
> > > 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
> > 
> 
> ---
>  Did I help you?   http://www.derickrethans.nl/link.php?url=giftlist
>  Frequent ranting: http://www.derickrethans.nl/
> ---
>  PHP: Scripting the Web - [EMAIL PROTECTED]
> All your branches are belong to me!
> SRM: Script Running Machine - www.vl-srm.net
> ---
> 
> 
> -- 
> 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] phpthreads - hints anyone...

[Jason T. Greene]

Instead of mutexing the entire interpreter to death, why don't you try
creating multiple interpreters (each in a thread), and then come up with
a sharing mechanism.

-Jason


On Wed, 2002-07-31 at 03:57, Alan Knowles wrote:
> Im looking at adding threading to php, (for the cgi/cli stuff)..
> 
> The story so far:
> 
> I've created an extension which diverts all zend_execute calls into the 
> extension -> phpthreads_execute.
> this function is a copy of zend_execute with a few modifications
> - to copy & restore things like  EG(active_symbol_table);
> - to malloc lock and unlock the execute loop and release on each opcode.
> 
> I've started testing the phpthreads_create($callback); - it appears to 
> work ok, execept it segfaults on completion.. - trying to reduce 
> refcounts somewhere.
> 
> The fireup code looks something like this..
> 
> void phpthreads_create(void *ptr) {
> zval myretval;
> zval *callback = (zval *) ptr;
>   
> if (!call_user_function( EG(function_table), NULL, callback, 
> &myretval, 0, NULL TSRMLS_CC ))  {
> zend_error(E_ERROR, "Problem Starting thread with 
> callback");
> }
>
> pthread_exit(NULL);
>
>
> }
> /* {{{ proto string phpthreads_thread(string function)
>Return a string to confirm that the module is compiled in */
> PHP_FUNCTION(phpthreads_create)
> {
>  
> zval *callback;
> pthread_t thread;
>
>   if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "z", 
> &callback) == FAILURE) {
>   return;
>   }
> pthread_create( &thread, NULL, (void *) phpthreads_create, 
> (void*) callback);
> RETURN_TRUE;
> }
> 
> and the backtrace of the simple threaded test looks like this..
> 0x08128f08 in _zval_ptr_dtor (zval_ptr=0x81b5ce8) at 
> /usr/src/php/php4/Zend/zend_execute_API.c:275
> 275 (*zval_ptr)->refcount--;
> (gdb) bt
> #0  0x08128f08 in _zval_ptr_dtor (zval_ptr=0x81b5ce8) at 
> /usr/src/php/php4/Zend/zend_execute_API.c:275
> #1  0x424ceba2 in ?? ()
> #2  0x424c7c92 in ?? ()
> #3  0x08130588 in zend_execute_scripts (type=8, retval=0x0, 
> file_count=3) at /usr/src/php/php4/Zend/zend.c:810
> #4  0x08110abd in php_execute_script (primary_file=0x40006c71) at 
> /usr/src/php/php4/main/main.c:1398
> #5  0x08110138 in php_module_shutdown () at 
> /usr/src/php/php4/main/main.c:1058
> #6  0x2e325f43 in ?? ()
> 
> does anyone want to suggest what might be missing - is it worth putting 
> this into pecl - and does someone what to lend a hand??
> 
> regards
> alan
> 
> 
> 
> 
> 
> 
> -- 
> 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] CVS Account Request: bobo

[Jason O Kaminsky]

James Cox said I should sign up for one, since Rackshack.net is going to be hosting 
your new server, and It will be easier to do some serverside admining this way

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

[PHP-DEV] [PATCH] ZEND_TICKS: allow modules to set a default

[Jason Greene]

This simple patch gives modules the ability to redefine the default
value for ticks generation. This patch assists another that I am
currently working on, which modifies pcntl to use TICKS as the backend,
instead of debug hooks in the zend engine.

Questions, Comments?

Thanks,
-Jason




? zend_ticks_default.diff
Index: zend.c
===
RCS file: /repository/Zend/zend.c,v
retrieving revision 1.146
diff -u -r1.146 zend.c
--- zend.c  18 Jun 2002 07:29:13 -  1.146
+++ zend.c  15 Jul 2002 05:36:21 -
@@ -265,6 +265,7 @@
CG(short_tags) = 1;
CG(allow_call_time_pass_reference) = 1;
CG(extended_info) = 0;
+   CG(declarables).ticks_default = 0;
 }
 
 
Index: zend_compile.c
===
RCS file: /repository/Zend/zend_compile.c,v
retrieving revision 1.232
diff -u -r1.232 zend_compile.c
--- zend_compile.c  29 Jun 2002 11:25:20 -  1.232
+++ zend_compile.c  15 Jul 2002 05:36:24 -
@@ -63,7 +63,7 @@
 static void init_compiler_declarables(TSRMLS_D)
 {
CG(declarables).ticks.type = IS_LONG;
-   CG(declarables).ticks.value.lval = 0;
+   CG(declarables).ticks.value.lval = CG(declarables).ticks_default;
 }
 
 
Index: zend_globals.h
===
RCS file: /repository/Zend/zend_globals.h,v
retrieving revision 1.86
diff -u -r1.86 zend_globals.h
--- zend_globals.h  22 Jun 2002 14:25:27 -  1.86
+++ zend_globals.h  15 Jul 2002 05:36:25 -
@@ -61,6 +61,7 @@
 
 typedef struct _zend_declarables {
zval ticks;
+   long ticks_default;
 } zend_declarables;
 
 



-- 
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 fsock.c

[Jason Greene]

vc++ compiler understands nested blocks just fine. The problem is that
err  is used further down in the file, and err is out of scope at that
point.

-Jason

On Sat, 2002-07-13 at 04:01, Jani Taskinen wrote:
> On Sat, 13 Jul 2002, Sebastian Bergmann wrote:
> 
> >Jani Taskinen wrote:
> >> What's the error you get?
> >
> >  c:\home\php\php4\ext\standard\fsock.c(244): error C2065:
> >  'err': undeclared identifier
> 
> So that stupid compiler doesn't understand this:
> 
> .
> .
> 
> {
>   int err;
>   . 
>   .
> }
> 
> ??? 
> 
> This stuff works with gcc and is used also elsewhere..
> Why doesn't it work there? :(
> 
> --Jani   
> 
> 
> 
> -- 
> 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] How do you format a string with tabbed output toprint in the browser? Nothing seems to work!

[Jason T. Greene]

Gina, 

This list is for the development OF php not with php, please post
questions like these to [EMAIL PROTECTED]

-Jason


On Mon, 2002-07-08 at 14:17, Planet Internet Nieuws wrote:
> I've tried everything I can think of including variations with "\t" in a
> printf(), chr(9), etc.  I am trying to create a file based on form input
> that will have columns of numbers with headings for those numbers.  After I
> process the form I write it to a file with the tabs.  I'd like to print that
> file to the screen to let the user see what was written.  This all works
> sans the tabs.  It's driving me nuts!!  I know that whitespace is ignored,
> but when you use printf() I thought PHP was suppose to format the output.  I
> can't even get the fixed number of spaces to work with padding--it just
> generates a bunch of whitespace that the browser ignores.
> 
> Please HELP!!!
> 
> Thanks,
> 
> -Gina
> 
> 
> 
> -- 
> 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] Komodo (PHP) Intergrated Development Environment Problems

[Jason McCormack]

Hi All,

Has anyone out there had any luck getting Komodo 1.2.6 to debug PHP? I have
been banging my head against the wall with no luck. I went through the docs
they supply - no luck. I compiled PHP as a module for Apache 1.13.22 on
Mandrake 8.1. Any help would be greatly appreciated.

Thanks,
Jason



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

[PHP-DEV] Jason back from vacation

[Jason T. Greene]

Everyone,

I am finally back from vacation, and I will be playing catch-up for a
while.(my email box has over 1000 msgs and I have missed about 1928
php-dev posts, I am sure the equiv CVS posts. )

Please give me some time to catch up.

Thanks,
-Jason


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

[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] PHP in thefuture

[Jason T. Greene]

True, I hear it is even possible to reuse code in COBOL : )

I believe that the ease of maintenance depends purely on the language.
i.e. using a strictly procedural language for a large framework can be
quite messy. Have you ever seen large libraries written in perl that
consistently call "require" on a million files.

PEAR is a good example of a framework that ran into a lot of limitations
of the language, which ZE2 will provide a great deal of help in.

-Jason


On Fri, 2002-06-07 at 09:36, Zeev Suraski wrote:
> Code reusability is a psychological issue.  You can reuse code in PHP 4, 
> and it'll be even better in 5 - PEAR is a clear demonstration of 
> this.  Whether people actually end up reusing code depends on the way they 
> code, very little does it depend on the language.
> 
> Zeev
> 
> At 05:27 PM 6/7/2002, Jason T. Greene wrote:
> >IMO, one of the big reasons for having a powerful OO mode, and
> >continually evolving php to have a bigger target than just "a web
> >programming language", is code re-usability. You can design a nice
> >consistent Framework, and easily rollout web, gui, and  back end
> >applications all using the same framework.
> >
> >-Jason
> 



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

[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] PHP in thefuture

[Jason T. Greene]

IMO, one of the big reasons for having a powerful OO mode, and
continually evolving php to have a bigger target than just "a web
programming language", is code re-usability. You can design a nice
consistent Framework, and easily rollout web, gui, and  back end
applications all using the same framework.

-Jason


On Fri, 2002-06-07 at 07:04, Kristian Koehntopp wrote:
> Am Donnerstag, 6. Juni 2002 19:59 schrieb Dan Hardiker:
> > I sit in many PHP channels (IRC), and observe many class-based
> > PHP networks (php-classes.org is one I monitor closely) and
> > can say definatly that the majority of PHP users want *more*
> > OO capabilities in PHP. 
> 
> From a marketing POV, what most people want is NOT more OOP in 
> PHP, but actually a hostable Java.
> 
> PHP is everywhere and pretty much free, when it comes to webspace 
> hosting. Java usually isn't, because it has certain requirements 
> for its execution environment that cannot be met in cheap 
> hosting environments.
> 
> So when users ask for "more OO" in PHP, they usually want Java 
> and Java capabilities for the price of their current PHP site, 
> and a migration path towards this. Since there is no such thing, 
> they end up trying to turn PHP into Java.
> 
> Kristian
> 



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

Re: [PHP-DEV] Re: Patch-tastic!

[Jason T. Greene]

If '+' concatenates what does '-' do?

: )

-Jason




On Wed, 2002-06-05 at 09:39, Andrei Zmievski wrote:
> > > The latest one changes some operators.
> > 
> >   Nice, but why not overload + for strings to do the concatenation?
> 
> Doing that would be ambiguous, to say the least. PHP automatically
> converts operand types with arithmetic + operator. What would you expect
> the result of the following expressions to be:
> 
>   "1" + "2"
>   1 + "2"
>   "2" + $a
> 
> -Andrei   http://www.gravitonic.com/
> * 2 + 2 = 5 for extremely large values of 2. *
> 
> -- 
> 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] socket_select() problems?

[Jason Greene]

Just to clarify the "horrible" interface. Yes, it could have been
written differently, though I did not want to drift to far from the C
API semantics(which I believe are perfectly fine). I posted the API
rewrite agenda(which made it into 4.2.0), several updates, examples,and
answered questions quite awhile ago. 

True the documentation is lacking, though I have not had the time to
work on it. I am planning on spending a lot of time before 4.3.0 because
I would lake to change the status of this extension from EXPERIMENTAL to
STABLE

socket_select() behaves exactly as the select() system call with a few
exceptions.

1. fd_sets are arrys: This means instead of FD_ISSET, use in_array() 
This also allows all the nice/powerful php features, such as using
array_walk()
2. It returns FALSE on error instead of -1
3. It forces you to at least pass one array, because some OS's socket
implementation (namely win32) does not allow select to be used as a wait
call

-Jason



On Sun, 2002-06-02 at 09:33, Rasmus Lerdorf wrote:
> Yeah, I guess so.  It just isn't very clear how this is mapped to PHP in
> the current docs.  I will write up some better docs.
> 
> -Rasmus
> 
> On Sun, 2 Jun 2002 [EMAIL PROTECTED] wrote:
> 
> > On Sat, 1 Jun 2002, Rasmus Lerdorf wrote:
> >
> > > So you save the original array of sockets to pass back in.  This is why
> > > the C API has FD_ISSET() to check the result of a select().  I really
> > > don't like this current behaviour of socket_select().  It will confuse the
> > > hell out of anybody coming at this from a C background.
> >
> > I always thought the C select() function also mangles the sets:
> >
> > (from 'man select')
> >
> >On  exit,  the  sets  are  modified in place to indicate which
> >descriptors actually changed status.
> >
> >
> > regards,
> > Derick
> >
> > > On Sun, 2 Jun 2002, Philip Olson wrote:
> > >
> > > > I only get [0], never [1].  Did about 40 tries.
> > > >
> > > >   latest CVS
> > > >   ./configure --enable-sockets
> > > >
> > > > If you need more info, let me know.
> > > >
> > > > Regards,
> > > > Philip Olson
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > PHP Development Mailing List <http://www.php.net/>
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> >
> > ---
> >  Did I help you?   http://www.jdimedia.nl/derick/link.php?url=giftlist
> >  Frequent ranting: http://www.jdimedia.nl/derick/
> > ---
> >  PHP: Scripting the Web - [EMAIL PROTECTED]
> > All your branches are belong to me!
> > SRM: Script Running Machine - www.vl-srm.net
> > ---
> >
> >
> > --
> > 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] socket_select() problems?

[Jason Greene]

On Mon, 2002-06-03 at 23:07, Jason Greene wrote:
> That is the most common mistake when using select() (Arguments are
> value-result) I think this motivated the different behavior of the
> poll() call.
> 
> There probably should be a large blurb in the docs to help out with this
> one.

I just noticed there is a notice now, oh well. This is what i get for
getting behind with my email. 

-Jason

> -Jason
> 
> 
> On Sun, 2002-06-02 at 09:33, Rasmus Lerdorf wrote:
> > Yeah, I guess so.  It just isn't very clear how this is mapped to PHP in
> > the current docs.  I will write up some better docs.
> > 
> > -Rasmus
> > 
> > On Sun, 2 Jun 2002 [EMAIL PROTECTED] wrote:
> > 
> > > On Sat, 1 Jun 2002, Rasmus Lerdorf wrote:
> > >
> > > > So you save the original array of sockets to pass back in.  This is why
> > > > the C API has FD_ISSET() to check the result of a select().  I really
> > > > don't like this current behaviour of socket_select().  It will confuse the
> > > > hell out of anybody coming at this from a C background.
> > >
> > > I always thought the C select() function also mangles the sets:
> > >
> > > (from 'man select')
> > >
> > >On  exit,  the  sets  are  modified in place to indicate which
> > >descriptors actually changed status.
> > >
> > >
> > > regards,
> > > Derick
> > >
> > > > On Sun, 2 Jun 2002, Philip Olson wrote:
> > > >
> > > > > I only get [0], never [1].  Did about 40 tries.
> > > > >
> > > > >   latest CVS
> > > > >   ./configure --enable-sockets
> > > > >
> > > > > If you need more info, let me know.
> > > > >
> > > > > Regards,
> > > > > Philip Olson
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > PHP Development Mailing List <http://www.php.net/>
> > > > To unsubscribe, visit: http://www.php.net/unsub.php
> > > >
> > >
> > > ---
> > >  Did I help you?   http://www.jdimedia.nl/derick/link.php?url=giftlist
> > >  Frequent ranting: http://www.jdimedia.nl/derick/
> > > ---
> > >  PHP: Scripting the Web - [EMAIL PROTECTED]
> > > All your branches are belong to me!
> > > SRM: Script Running Machine - www.vl-srm.net
> > > ---
> > >
> > >
> > > --
> > > PHP Development Mailing List <http://www.php.net/>
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> > 
> > 
> > -- 
> > PHP Development Mailing List <http://www.php.net/>
> > To unsubscribe, visit: http://www.php.net/unsub.php
> > 
> 
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 



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

Re: [PHP-DEV] socket_select() problems?

[Jason Greene]

That is the most common mistake when using select() (Arguments are
value-result) I think this motivated the different behavior of the
poll() call.

There probably should be a large blurb in the docs to help out with this
one.

-Jason


On Sun, 2002-06-02 at 09:33, Rasmus Lerdorf wrote:
> Yeah, I guess so.  It just isn't very clear how this is mapped to PHP in
> the current docs.  I will write up some better docs.
> 
> -Rasmus
> 
> On Sun, 2 Jun 2002 [EMAIL PROTECTED] wrote:
> 
> > On Sat, 1 Jun 2002, Rasmus Lerdorf wrote:
> >
> > > So you save the original array of sockets to pass back in.  This is why
> > > the C API has FD_ISSET() to check the result of a select().  I really
> > > don't like this current behaviour of socket_select().  It will confuse the
> > > hell out of anybody coming at this from a C background.
> >
> > I always thought the C select() function also mangles the sets:
> >
> > (from 'man select')
> >
> >On  exit,  the  sets  are  modified in place to indicate which
> >descriptors actually changed status.
> >
> >
> > regards,
> > Derick
> >
> > > On Sun, 2 Jun 2002, Philip Olson wrote:
> > >
> > > > I only get [0], never [1].  Did about 40 tries.
> > > >
> > > >   latest CVS
> > > >   ./configure --enable-sockets
> > > >
> > > > If you need more info, let me know.
> > > >
> > > > Regards,
> > > > Philip Olson
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > PHP Development Mailing List <http://www.php.net/>
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> >
> > ---
> >  Did I help you?   http://www.jdimedia.nl/derick/link.php?url=giftlist
> >  Frequent ranting: http://www.jdimedia.nl/derick/
> > ---
> >  PHP: Scripting the Web - [EMAIL PROTECTED]
> > All your branches are belong to me!
> > SRM: Script Running Machine - www.vl-srm.net
> > ---
> >
> >
> > --
> > 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] Re: [Zend Engine 2] Re: [PHP-DEV] [RESENT] [PATCH]Allow constants / expressions to be passed by reference]

[Jason T. Greene]

On Wed, 2002-05-29 at 13:53, Andi Gutmans wrote:
> Okay I'll try and look at your patch in the next couple of days.
> It's quite sensitive code which this changes (has harmless as it might 
> seem) so I need some time to read over it.
Thanks, I did test this very thoroughly. However, due to its possible
far reaching effects, I would appreciate someone else taking their time
on a careful review.

I understand if it takes you awhile to get to it

-Jason

> Andi
> 



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

Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] [RESENT] [PATCH] Allowconstants / expressions to be passed by reference]

[Jason T. Greene]

Even if it is semantically incorrect( which I disagree.)

How is allowing a constant/expression to be passed by reference more
"semantically incorrect"  than allowing a default (which is a constant)
on a pass by reference argument?

-Jason


On Wed, 2002-05-29 at 10:53, Sebastian Bergmann wrote:
> Andi Gutmans wrote:
> > I don't see any reason to allow passing non-variables by reference.
> > It is semantically incorrect.
> 
>   +1
> 
> -- 
>   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: [Fwd: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] [RESENT][PATCH] Allow constants / expressions to be passed by reference]]

[Jason T. Greene]

Yes and as I said in my argument, this solves some of the problems but
does not solve a non-rightmost parameter being optional.

-Jason

On Wed, 2002-05-29 at 11:43, Sebastian Bergmann wrote:
>   Hamster ate my mail? Resent, just in case.
> 
> Sebastian Bergmann wrote:
> > brad lafountain wrote:
> >> function foo(&$bar = null)
> >> {
> >> }
> >
> >  This has already been "fixed" for the Zend Engine 2:
> >
> > * Parameters that are passed by reference to a function
> >   may now have default values.
> >
> >   Example:
> >
> >  > function my_function(&$var = null) {
> >  if ($var === null) {
> >  die('$var needs to have a value');
> >  }
> > }
> > ?>
> >
> >   (Source: /ZendEngine2/ZEND_CHANGES)
> 
> -- 
>   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] Re: [Zend Engine 2] Re: [PHP-DEV] [RESENT] [PATCH]Allow constants / expressions to be passed by reference]

[Jason T. Greene]

Andi, 

I do not see how this is semantically incorrect, or how it is that much
different than allowing default values for pass by reference arguments.
IMO The only useful reason to deny passing a constant/expression in a
function is to provide a warning message. Some of the problems I
outlined in my post can be solved using default values(only using ZE2,
which allows defaults on reference args); however, default values only
solve rightmost optional parameters. i.e. there is no way to do:

function a($arg1, $arg2="blah", $arg3="blah"){}


a(1, ,3)

In respect to not passing by reference, this problem is solved by doing
the following 

function magic_function($var1, $var2, $var3) {
// Note just an example - I would usually use func_get_args...
if ($var2 === NULL) {
$var2 = "blah";
}
}

magic_function(1, NULL, 3);

This technique of course will not work with the current semantics of not
allowing constants/expressions to pass by reference.

-Jason





On Wed, 2002-05-29 at 10:26, Andi Gutmans wrote:
> I don't see any reason to allow passing non-variables by reference.
> It is semantically incorrect.
> 
> Andi
> 
> At 09:40 29/05/2002 +0200, Stig S. Bakken wrote:
> >If this patch doesn't break anything, and it doesn't give us any
> >difficulties with ZE2 or major design issues, I'm +1.
> >
> >  - Stig
> >
> >On Tue, 2002-05-28 at 21:12, Jason T. Greene wrote:
> > > Due to this patch being sent during the msession discussion, it has not
> > > been noticed, so I am resending.
> > >
> > >
> > > -Jason
> > > 
> > >
> >
> > > From: Jason Greene <[EMAIL PROTECTED]>
> > > To: [EMAIL PROTECTED]
> > > Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
> > > Subject: [PHP-DEV] [PATCH] Allow constants / expressions to be passed 
> > by reference
> > > Date: 25 May 2002 02:18:52 -0500
> > >
> > > Problem
> > > ---
> > >
> > > There are some scenarios where a function requires the ability to modify
> > > parameters that may also be optional. Optional parameters work well,
> > > except in the scenario where all of the pass by reference parameters can
> > > be optional. ex the socket_select() function. Since select is
> > > argument-result, all three arrays that are taken as input must be passed
> > > by reference, yet any can be excluded. So for example if you were
> > > calling socket_select with a read socket array, a write socket array,
> > > yet no exception array (quite common), you are currently forced to do
> > > something like the following:
> > >
> > > $wfds = array($sock1, $sock2);
> > > $rfds = array($sock3, $sock4);
> > > $null = NULL;
> > >
> > > socket_select($rfds, $wfds, $null);
> > >
> > >
> > > I have ran into this problem before several times while developing in
> > > user space. (Especially when passing around semi-complex data
> > > structures)
> > >
> > > Proposed Solution
> > > --
> > >
> > > Allow all expressions to be passed by reference. This will allow
> > > something like the following
> > >
> > > function  normalize(&$element_tree, &$node_mapping, $max_depth){
> > > //Code
> > > }
> > >
> > > normalize($my_tree, NULL, 25000);
> > >
> > >
> > > Patch
> > > --
> > >
> > > I have attached a patch against ZE2 that accomplishes this.
> > >
> > >
> > > Thanks,
> > > -Jason
> > >
> > >
> > >
> > >
> > >
> > > 
> > >
> >
> > > Index: zend_compile.c
> > > ===
> > > RCS file: /repository/ZendEngine2/zend_compile.c,v
> > > retrieving revision 1.285
> > > diff -u -r1.285 zend_compile.c
> > > --- zend_compile.c23 Apr 2002 18:06:53 -  1.285
> > > +++ zend_compile.c25 May 2002 06:45:21 -
> > > @@ -1271,7 +1271,7 @@
> > >   op = ZEND_SEND_REF;
> > >   break;
> > >   default:
> > > - zend_error(E_COMPILE_ERROR, "Only 
> > variables can be passed by reference");
> > > + op = ZEND_SEND_VAR;
> > >   break;
> > >   }
> > >   }
>

[PHP-DEV] [RESENT] [PATCH] Allow constants / expressions to be passed byreference]

[Jason T. Greene]

Due to this patch being sent during the msession discussion, it has not
been noticed, so I am resending.


-Jason

--- Begin Message ---

Problem
---

There are some scenarios where a function requires the ability to modify
parameters that may also be optional. Optional parameters work well,
except in the scenario where all of the pass by reference parameters can
be optional. ex the socket_select() function. Since select is
argument-result, all three arrays that are taken as input must be passed
by reference, yet any can be excluded. So for example if you were
calling socket_select with a read socket array, a write socket array,
yet no exception array (quite common), you are currently forced to do
something like the following:

$wfds = array($sock1, $sock2);
$rfds = array($sock3, $sock4);
$null = NULL;

socket_select($rfds, $wfds, $null);


I have ran into this problem before several times while developing in
user space. (Especially when passing around semi-complex data
structures)

Proposed Solution
--

Allow all expressions to be passed by reference. This will allow
something like the following

function  normalize(&$element_tree, &$node_mapping, $max_depth){
//Code
}

normalize($my_tree, NULL, 25000);


Patch
--

I have attached a patch against ZE2 that accomplishes this. 


Thanks,
-Jason







Index: zend_compile.c
===
RCS file: /repository/ZendEngine2/zend_compile.c,v
retrieving revision 1.285
diff -u -r1.285 zend_compile.c
--- zend_compile.c  23 Apr 2002 18:06:53 -  1.285
+++ zend_compile.c  25 May 2002 06:45:21 -
@@ -1271,7 +1271,7 @@
op = ZEND_SEND_REF;
break;
default:
-   zend_error(E_COMPILE_ERROR, "Only variables can be 
passed by reference");
+   op = ZEND_SEND_VAR;
break;
}
}
Index: zend_execute.c
===
RCS file: /repository/ZendEngine2/zend_execute.c,v
retrieving revision 1.341
diff -u -r1.341 zend_execute.c
--- zend_execute.c  8 May 2002 18:43:19 -   1.341
+++ zend_execute.c  25 May 2002 06:45:25 -
@@ -2292,10 +2292,6 @@
NEXT_OPCODE();
}
case ZEND_SEND_VAL: 
-   if (EX(opline)->extended_value==ZEND_DO_FCALL_BY_NAME
-   && 
ARG_SHOULD_BE_SENT_BY_REF(EX(opline)->op2.u.opline_num, EX(fbc), 
EX(fbc)->common.arg_types)) {
-   zend_error(E_ERROR, "Cannot pass 
parameter %d by reference", EX(opline)->op2.u.opline_num);
-   }
{
zval *valptr;
zval *value;
@@ -2329,7 +2325,8 @@

zend_ptr_stack_push(&EG(argument_stack), varptr);
NEXT_OPCODE();
}
-   zend_error(E_ERROR, "Only variables can be 
passed by reference");
+   /* Should only occur with an uninitialized 
+variable */
+   goto send_by_var;
}
NEXT_OPCODE();
case ZEND_SEND_VAR:



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

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

[PHP-DEV] [PATCH] Allow constants / expressions to be passed by reference

[Jason Greene]

Problem
---

There are some scenarios where a function requires the ability to modify
parameters that may also be optional. Optional parameters work well,
except in the scenario where all of the pass by reference parameters can
be optional. ex the socket_select() function. Since select is
argument-result, all three arrays that are taken as input must be passed
by reference, yet any can be excluded. So for example if you were
calling socket_select with a read socket array, a write socket array,
yet no exception array (quite common), you are currently forced to do
something like the following:

$wfds = array($sock1, $sock2);
$rfds = array($sock3, $sock4);
$null = NULL;

socket_select($rfds, $wfds, $null);


I have ran into this problem before several times while developing in
user space. (Especially when passing around semi-complex data
structures)

Proposed Solution
--

Allow all expressions to be passed by reference. This will allow
something like the following

function  normalize(&$element_tree, &$node_mapping, $max_depth){
//Code
}

normalize($my_tree, NULL, 25000);


Patch
--

I have attached a patch against ZE2 that accomplishes this. 


Thanks,
-Jason







Index: zend_compile.c
===
RCS file: /repository/ZendEngine2/zend_compile.c,v
retrieving revision 1.285
diff -u -r1.285 zend_compile.c
--- zend_compile.c  23 Apr 2002 18:06:53 -  1.285
+++ zend_compile.c  25 May 2002 06:45:21 -
@@ -1271,7 +1271,7 @@
op = ZEND_SEND_REF;
break;
default:
-   zend_error(E_COMPILE_ERROR, "Only variables can be 
passed by reference");
+   op = ZEND_SEND_VAR;
break;
}
}
Index: zend_execute.c
===
RCS file: /repository/ZendEngine2/zend_execute.c,v
retrieving revision 1.341
diff -u -r1.341 zend_execute.c
--- zend_execute.c  8 May 2002 18:43:19 -   1.341
+++ zend_execute.c  25 May 2002 06:45:25 -
@@ -2292,10 +2292,6 @@
NEXT_OPCODE();
}
case ZEND_SEND_VAL: 
-   if (EX(opline)->extended_value==ZEND_DO_FCALL_BY_NAME
-   && 
ARG_SHOULD_BE_SENT_BY_REF(EX(opline)->op2.u.opline_num, EX(fbc), 
EX(fbc)->common.arg_types)) {
-   zend_error(E_ERROR, "Cannot pass 
parameter %d by reference", EX(opline)->op2.u.opline_num);
-   }
{
zval *valptr;
zval *value;
@@ -2329,7 +2325,8 @@

zend_ptr_stack_push(&EG(argument_stack), varptr);
NEXT_OPCODE();
}
-   zend_error(E_ERROR, "Only variables can be 
passed by reference");
+   /* Should only occur with an uninitialized 
+variable */
+   goto send_by_var;
}
NEXT_OPCODE();
case ZEND_SEND_VAR:



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

[PHP-DEV] CVS Account Request: jrust

[Jason Rust]

Martin told me to get a CVS account here so I can contribute to PEAR.

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

Re: [PHP-DEV] Safe Mode

[Jason T. Greene]

On Mon, 2002-05-13 at 09:54, Ilia A. wrote:
> > Now you are really starting to stretch it. I am sure the ratio of
> > customers that have db backends are much smaller than general webhosting
> > customers
> 
> PHP is very commonly used with a database (MySQL). I'd venture to say that 70% 
> of people who actively use PHP use it with MySQL or another database system.

You are probably correct about that.
> >
> > In all of these scenarios, the webserver itself would just spawn another
> > process, and the os would page the other one because it is not in use,
> > and then eventually the webserver would log the problem.
> >
> > If you factor that in with a shared environment with multiple webservers
> > and a load balance, your risk is pretty low. Even if someone did do
> > something like that to kill all of your webservers, you would easily be
> > able to find out who did it, and fix the abuser.
> 
> You could track down the abusee easily, simply using Apache's server-status to 
> see what each process is doing. But if you are tracking down the abuser you 
> are already too late because the problem had already occured and now you are 
> doing damage control. Sure you remove this user, but what about the next one?
> 
> > how are you planning on protecting your passwd file then?
> 
> Simple, use the file permissions to prevent the webserver from accessing it. 
> Or put the webserver inside a chroot jail, so it cannot even see parts of the 
> OS.
>

All processes have to have access to /etc/passwd. Try disabling access
to it, everything will break because all uid calls will fail

I was pointing out that OS permissions can not fix the problem. 

Yes, you can perform a chroot(), however then you have to use php as a
cgi which kills performance. Though wrapping a fastcgi interpreter with
suexec might be a much better solution.When you do build a chroot area
you have to put a bogus /etc/passwd. Both open_basedir and safe_mode
protect /etc/passwd. 

(Well for safe_mode, after the show_source() vulnerability you found was
fixed. However open_basedir still would have prevented that)

> >
> > > If you have sensetive data, like credit card information and you are not
> > > using a dedicated server to store that data then do be surprised to find
> > > your data in someone elses hands. In a shared enviroment especially where
> > > programming/scripting languages are avaliable it is merely a matter of
> > > time before someone takes advantage of some security hole/oversight and
> > > grabs the hold of your data.
> >
> > So then you are agreeing : )
> 
> If your making a point about people with sensetive data needing their own 
> servers, then yes, I whole heartedly agree with you.
> 
> > Or you could try something more useful, like fixing a bug in safe mode,
> > adding a new security feature, etc. etc. However, I suppose it is too
> > difficult to come up with a constructive solution.
> 
> I believe fixing bug in safe_mode is a pointless process because new ones will 
> appear instantly. Safe mode bugs have been fixed in every release since it 
> was first introduced and we still have problem. 
> 
> > Hmm, but you just said that a shared webhosting enviroment, by nature,
> > has no real safety.
> 
> It doesn't.
> 
> >
> > Pointlesly difficult.
> > then safe mode must be doing something
> 
> Yeah it is, making development a little slower because you need to make 
> safe_mode work arounds.
Yes that is unfortunate that restrictions can make development more
difficult.
> Ilia 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 



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

Re: [PHP-DEV] Safe Mode

[Jason T. Greene]

I very much agree : )

-Jason

On Mon, 2002-05-13 at 03:42, veins wrote:
> > He has a point in the sense that it's trivially easy to starve a PHP based
> > web server from within, safe mode enabled or not.  What you describe as
> the
> > automated way in which the web server will overcome this attack is not
> > realistic - pretty quickly, the web server would hit the maximum number of
> > children allowed, or (if improperly configured) run out of memory.
> 
> This is not PHP related. A web server improperly configured would run out
> of memory under a heavy load or with a CGI script.
> 
> > Fact is, safe mode doesn't even attempt to guard against this.  Not that I
> > think it can be guarded against, even if we were trying to do it.  And a
> > direct derived fact is that PHP is not safe to allow untrusted users to
> run
> > code.
> 
> I happen to think that allowing untrusted users to run PHP code is safer
> than
> allowing them to run a CGI script, even if PHP is not under safe_mode and
> that CGI is chroot()-ed.
> 
> > I personally don't think that this was the idea behind safe mode - the
> idea
> > behind safe mode was to guard against information leaking in between
> users,
> > not against some renegade user that wants to bring the web server
> > down.  And, I've been advocating the removal of safe mode for years,
> > because even at that, it does a pretty bad job.  Not because it's poorly
> > implemented, but because it's protection in the wrong level, that by
> > definition, is bound to fail.  And, I think we all agree that a false
> sense
> > of security is worse than no security at all.
> 
> I don't. I don't see safe_mode as a "false sense" of security, I see it as
> another
> layer to be used with other security mechanisms. I would surely not run a
> web
> server with safe_mode being the only security, but I would not even run PHP
> without the safe_mode option. And many admins wouldn't...
> 
> > Ilya illustrated what I was saying a while ago, about the inherent (woo,
> > this word again! :) vulnerability of safe mode, by design.  When I said
> it,
> > I didn't invest any resources into proving that this inherent
> vulnerability
> > is actually exploitable, he did.  I believe that encouraging people to use
> > CGI (and fast CGI as a performance solution) is probably the only way to
> > go.  And I agree with Stig that PHP 5.0 would be the right point in time
> to
> > do that.
> 
> Encouraging people to use CGI is an utopia, there are environnements where
> CGI cannot be "offered" to customers and where PHP is the only option. The
> ability to use safe_mode (again, as another layer and not as the only
> security)
> is a nice option, I really strongly believe that it shouldn't be taken apart
> from
> PHP.
> 
> veins
> 



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

Re: [PHP-DEV] Safe Mode

[Jason T. Greene]

On Mon, 2002-05-13 at 04:11, Zeev Suraski wrote:
> At 11:42 13/05/2002, veins wrote:
> > > He has a point in the sense that it's trivially easy to starve a PHP based
> > > web server from within, safe mode enabled or not.  What you describe as
> >the
> > > automated way in which the web server will overcome this attack is not
> > > realistic - pretty quickly, the web server would hit the maximum number of
> > > children allowed, or (if improperly configured) run out of memory.
> >
> >This is not PHP related. A web server improperly configured would run out
> >of memory under a heavy load or with a CGI script.
> 
> Right, I didn't suggest otherwise.
> 
> > > Fact is, safe mode doesn't even attempt to guard against this.  Not that I
> > > think it can be guarded against, even if we were trying to do it.  And a
> > > direct derived fact is that PHP is not safe to allow untrusted users to
> >run
> > > code.
> >
> >I happen to think that allowing untrusted users to run PHP code is safer
> >than
> >allowing them to run a CGI script, even if PHP is not under safe_mode and
> >that CGI is chroot()-ed.
> 
> I don't agree with that.  chroot() is stronger than anything PHP can ever 
> hope to offer.
> 
> >I don't. I don't see safe_mode as a "false sense" of security, I see it as
> >another
> >layer to be used with other security mechanisms.
> 
> I do, for two simple reasons:
> - Misperception about what it's supposed to do - it does NOT secure your 
> environment, people expect it to.  That's a 'marketing' issue, but we 
> should realize that these kinds of issues are at least as important as the 
> technical ones.


I get the feeling that you are mainly arguing the marketing perspective.

: )


I completely agree that safe mode is badly named. However, I still find
uid checking, and restricting process spawning very useful


> - Inherent flaws in the way it does what it IS supposed to do.  Guarding 
> users against each other at this level is a lost cause.  Even if you know 
> perfectly well what safe mode's supposed to do, whatever sense of security 
> you get from it is false, because there are always going to be slightly 
> more or slightly less trivial ways of defeating it.
 
> >Encouraging people to use CGI is an utopia, there are environnements where
> >CGI cannot be "offered" to customers and where PHP is the only option.
> 
> I don't think you understood the context.  We're talking about the PHP CGI, 
> not CGI in general.

> Zeev
> 



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

Re: [PHP-DEV] Safe Mode

[Jason T. Greene]

On Mon, 2002-05-13 at 03:13, Zeev Suraski wrote:
> Jason,
> 
> He has a point in the sense that it's trivially easy to starve a PHP based 
> web server from within, safe mode enabled or not.  What you describe as the 
> automated way in which the web server will overcome this attack is not 
> realistic - pretty quickly, the web server would hit the maximum number of 
> children allowed, or (if improperly configured) run out of memory.

Right, if we are talking a brute force and it is large enough, that
could occur. However, you don't need php to brute force a webserver.
I was arguing that the risk is a lot lower than ilia was making it out
to be.

> Fact is, safe mode doesn't even attempt to guard against this.  Not that I 
> think it can be guarded against, even if we were trying to do it.  And a 
> direct derived fact is that PHP is not safe to allow untrusted users to run 
> code.

It has absolutely nothing to do with PHP, end everything to do with a
shared hosting environment.


> I personally don't think that this was the idea behind safe mode - the idea 
> behind safe mode was to guard against information leaking in between users, 
> not against some renegade user that wants to bring the web server 
> down.  And, I've been advocating the removal of safe mode for years, 
> because even at that, it does a pretty bad job.  Not because it's poorly 
> implemented, but because it's protection in the wrong level, that by 
> definition, is bound to fail.  And, I think we all agree that a false sense 
> of security is worse than no security at all.

I do not think that safe mode is the end all be all of protection
mechanisms. I do think the security it provides can be pretty useful,
and when added with other mechanisms, can greatly limit vulnerabilities.

I for instance have used safe mode + open basedir + in house chroot
customizations. All of these combined provide pretty good protection,
and I would not be comfortable with any one of them being removed,
unless an alternative can be found.

Just to be clear, I am not saying that safe mode is the way to go. I do
not like it when someone argues to remove something just because it has
a few bugs. Ilia never provided any better or alternative solutions,
just attacked exaggeratively what is currently available. 
 
> Ilya illustrated what I was saying a while ago, about the inherent (woo, 
> this word again! :) vulnerability of safe mode, by design.  When I said it, 
> I didn't invest any resources into proving that this inherent vulnerability 
> is actually exploitable, he did.

I really don't see how he proved anything, besides a few bugs in safe
mode


>  I believe that encouraging people to use 
> CGI (and fast CGI as a performance solution) is probably the only way to 
> go.  And I agree with Stig that PHP 5.0 would be the right point in time to 
> do that.


I noticed that FastCGI supports suexec wrapping, which could work very
well if you modify suexec to suid, and chroot. There would then be a php
interpreter running as the user, locked in a sandbox, with no shutdown,
startup penalty

-Jason

> Zeev
> 
> At 08:54 13/05/2002, Jason Greene wrote:
> >On Mon, 2002-05-13 at 00:41, Ilia A. wrote:
> > > > disable_functions = sleep
> > >
> > > Ah but you forgot usleep, and flock() and socket_set_limit etc...
> > > Soon enough you'll disable every function.
> >
> >Not likely, and I wouldn't disable every single function. You complained
> >about the ability, I provided you with the way that YOU can disable it.
> >You have to ask yourself why your user would need to be able to call
> >sleep
> >
> > > And when you do, I'll still be able to deadlock a PHP process by making it
> > > excute a query on a locked SQL table, thus end up waiting forever for the
> > > lock to be
> >e>leased. So, you'll need to disable all database functions from
> > > your PHP.
> > >
> >
> >Now you are really starting to stretch it. I am sure the ratio of
> >customers that have db backends are much smaller than general webhosting
> >customers
> >
> >In all of these scenarios, the webserver itself would just spawn another
> >process, and the os would page the other one because it is not in use,
> >and then eventually the webserver would log the problem.
> >
> >If you factor that in with a shared environment with multiple webservers
> >and a load balance, your risk is pretty low. Even if someone did do
> >something like that to kill all of your webservers, you would easily be
> >able to find out who did it, and fix the abuser.
> > > >
> > > > > > > > The argument you make to remove safe mode be

Re: [PHP-DEV] Safe Mode

[Jason Greene]

On Mon, 2002-05-13 at 00:41, Ilia A. wrote:
> > disable_functions = sleep
> 
> Ah but you forgot usleep, and flock() and socket_set_limit etc...
> Soon enough you'll disable every function.

Not likely, and I wouldn't disable every single function. You complained
about the ability, I provided you with the way that YOU can disable it.
You have to ask yourself why your user would need to be able to call
sleep

> And when you do, I'll still be able to deadlock a PHP process by making it 
> excute a query on a locked SQL table, thus end up waiting forever for the 
> lock to be 
e>leased. So, you'll need to disable all database functions from 
> your PHP.
> 

Now you are really starting to stretch it. I am sure the ratio of
customers that have db backends are much smaller than general webhosting
customers

In all of these scenarios, the webserver itself would just spawn another
process, and the os would page the other one because it is not in use,
and then eventually the webserver would log the problem.

If you factor that in with a shared environment with multiple webservers
and a load balance, your risk is pretty low. Even if someone did do
something like that to kill all of your webservers, you would easily be
able to find out who did it, and fix the abuser.
> >
> > > > > > The argument you make to remove safe mode because it is not perfect
> > > > > > is unfounded. By the same argument you could say we shouldn't use
> > > > > > locks on our doors, because hey "they can be picked".
> > > > >
> > > > > Safe mode is not only imperfect it does not even work properly. In
> > > > > the last day and a half I've showed 5 bugs that allow it be bypassed,
> > > > > simply take a look at the latest safe_mode bugs.
> > > >
> > > > Five, I only saw one. Regardless they can and should be fixed.
> > >
> > > Check again:
> > >
> > > Bug report #17168-69
> > > Bug report #17155-57
> >
> > All of those regarding safe mode are fixed now.
> 
> Really, you don't say... bug reports #17168-69 are still open at the time of 
> this message being written. And when they are closed, don't worry I'll have a 
> few more posted tommorow for your enjoyment...
> 
> > It depends on why the lock is broken, you have been suggesting this
> > whole time that safe mode is a DESIGN flaw. However, your reasoning is
> > only BUILD flaws. I have yet to hear a single reason as to why the
> > concept of extra uid, checks of files is a bad thing.
> 
> It is not PHPs job as a scripting/programming language to do security. 
> security should/must be done at the OS and web server level. Checking uid is 
> STUPID, the simplest example, is that if you upload a php script and it 
> creates a file you can no longer read or write to that file even though you 
> have file permissions to do so. 
> File system permissions exist for a reason, use them.

how are you planning on protecting your passwd file then?

> If you have sensetive data, like credit card information and you are not using 
> a dedicated server to store that data then do be surprised to find your data 
> in someone elses hands. In a shared enviroment especially where 
> programming/scripting languages are avaliable it is merely a matter of time 
> before someone takes advantage of some security hole/oversight and grabs the 
> hold of your data.


So then you are agreeing : )

> > There are problems here and you can be a bit more constructive, and send
> > patches, offer new security techniques, report bugs. Exaggerating and
> > cursing safe mode does nothing but waste time.


> I am clearly demonstrating the problem and if you actually payed attention 
> instead of trying to pretend this problem did not exist,

I am not, I am merely disagreeing that safe mode should be removed.  I
mean god man, if you hate safe mode so much turn it off. There are
options you know, but just because you don't like it does not mean that
everyone should not be able to use it.

 reporting bugs about 
> it. I'd gladly offer a patch that will get rid off safe_mode for the core php 
> tree if developers are willing to add it to the CVS :)

Or you could try something more useful, like fixing a bug in safe mode,
adding a new security feature, etc. etc. However, I suppose it is too
difficult to come up with a constructive solution.
> Safe mode wasteful and pointless this is no exageratio,n it makes development 
> in the "safe" enviroment pointlessly difficult and offers no real safety.
> 
> Ilia
Hmm, but you just said that a shared webhosting enviroment, by nature,
has no real safety.

Pointlesly difficult.
then safe mode must be doing something





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

Re: [PHP-DEV] Safe Mode

[Jason Greene]

On Sun, 2002-05-12 at 23:38, Ilia A. wrote:
> > Really, what is that line? 
> 
> sleep(1000);
> 
> If you insist on being creative you can use file locking or sockets to get the 
> process in to un-interuptible sleep.
> 
> > I would take a bet that it probably has
> > nothing to do with safe mode, and would work regardless of it being in
> > the language..
> 
> I am not saying this particular problem is due to safe_mode, which only 
> "theoreticaly" prevents people from viewing/modifying files they do not own. 
> I say theoretically because in reality a bugs in safe_mode can be used to 
> bypass this limitation or simply write code in another programming language 
> to do it. However, "safe mode" implies safety, which in reality it DOES NOT 
> offer, of course if the defenition of the word "safe" has changed, please let 
> me know.

Ok now you are changing your argument. If you say it is inappropriately
named, I will agree. However, the functionality of extra uid checks is a
good measure

The thing we have to hope for is that the admin is smart enough to
realize their is no such thing as perfect security


> > I will also take bet that there is another security
> > measure in php that can be used against it. 
> >
> 
> Don't bet on it, you'll loose.

disable_functions = sleep

> 
> > > > The argument you make to remove safe mode because it is not perfect is
> > > > unfounded. By the same argument you could say we shouldn't use locks on
> > > > our doors, because hey "they can be picked".
> > >
> > > Safe mode is not only imperfect it does not even work properly. In the
> > > last day and a half I've showed 5 bugs that allow it be bypassed, simply
> > > take a look at the latest safe_mode bugs.
> >
> > Five, I only saw one. Regardless they can and should be fixed.
> 
> Check again:
> 
> Bug report #17168-69
> Bug report #17155-57

All of those regarding safe mode are fixed now.
> 
> >
> > > Some of those were fixed other were not as
> > > yet. To continue with your lock analogy, you do not protect your house
> > > with a broken lock, because beyond cosmetic value it does absolutely
> > > nothing.
> >
> > If the lock is broken, you fix it, you don't get rid of the lock
> > altogether
> 
> If you've fixed the same lock a dosen times and it still breaks it is probably 
> smarter to get rid off it and get a new one.
> 
> Ilia

It depends on why the lock is broken, you have been suggesting this
whole time that safe mode is a DESIGN flaw. However, your reasoning is
only BUILD flaws. I have yet to hear a single reason as to why the
concept of extra uid, checks of files is a bad thing.

The fact of the matter, is that it is YOU who is ultimately responsible
for your systems security. When you allow thousands of users to share
the same system, and all execute arbitrary code on that system, there is
always the possibility of problems. You can not rely on PHP itself
solving all of your webhosting systems security problems. By the same
argument that you make to get rid of safe mode, we could tell you to not
use a shared environment, and use dedicated servers.

There are problems here and you can be a bit more constructive, and send
patches, offer new security techniques, report bugs. Exaggerating and
cursing safe mode does nothing but waste time.


-Jason


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

Re: [PHP-DEV] Safe Mode

[Jason Greene]

On Sun, 2002-05-12 at 22:46, Ilia A. wrote:
> > However, quite frankly, this is a lame attack, because all it will do is
> > consume file descriptors for only the CHILD process the script is
> > running in. The script will then hit the fd limit of the child process
> > (most systems around 255 is the default) This will not hurt the process,
> > because all needed file descriptors were opened before the script was
> > executed. The beauty of this is that the kernel will the reject all
> > future calls beyond the limit, which halts i/o usage, and causes the
> > process to consume more user time, which cause the process to hit max
> > execution limit. 
> 
> While the file description attack may be "lame" as you call it and won't cause 
> excessive harm. There are many other ways that 2-3 lines a webserver can be 
> brought down to its knees. If you want I can post code for A LOT more potent 
> attacks that will disable the webserver. I simply choose not to because I 
> believe that disclosing such information will do more harm then good.
> Even the "lame" file descriptor attack can be made very dangerous by adding of 
> 1 line of code.
> 
Really, what is that line? I would take a bet that it probably has
nothing to do with safe mode, and would work regardless of it being in
the language.. I will also take a bet that there is another security
measure in php that can be used against it.

> > The argument you make to remove safe mode because it is not perfect is
> > unfounded. By the same argument you could say we shouldn't use locks on
> > our doors, because hey "they can be picked".
> >
> 
> Safe mode is not only imperfect it does not even work properly. In the last 
> day and a half I've showed 5 bugs that allow it be bypassed, simply take a 
> look at the latest safe_mode bugs.

Five, I only saw one. Regardless they can and should be fixed.
> Some of those were fixed other were not as 
> yet. To continue with your lock analogy, you do not protect your house with a 
> broken lock, because beyond cosmetic value it does absolutely nothing.


If the lock is broken, you fix it, you don't get rid of the lock
altogether 
> 
> Ilia

-Jason



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

Re: [PHP-DEV] Safe Mode

[Jason Greene]

> while(1) fopen(rand(), "w");
> 
> After a few seconds depending on system speed system will run out of file 
> pointers. I am sure you can see how that would be BAD.

You are _extremely_ incorrect. The previously mentioned code would open
1 file descriptor repeatedly until the script hit max execution time.

This occurs because the garbage collector closes the unused file
descriptor with every iteration.

You could gain the desired effect of abusing file descriptors by using
the following code

while (1) $vars[]=fopen(rand(), "w");

However, quite frankly, this is a lame attack, because all it will do is
consume file descriptors for only the CHILD process the script is
running in. The script will then hit the fd limit of the child process
(most systems around 255 is the default) This will not hurt the process,
because all needed file descriptors were opened before the script was
executed. The beauty of this is that the kernel will the reject all
future calls beyond the limit, which halts i/o usage, and causes the
process to consume more user time, which cause the process to hit max
execution limit.

The argument you make to remove safe mode because it is not perfect is
unfounded. By the same argument you could say we shouldn't use locks on
our doors, because hey "they can be picked".

-Jason





> 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] Re: Bug #17022: enhance socket_strerror(errno) tomakeerrno optional

[Jason Greene]

I think he is referring to persistent sockets.

Tom, 

Could you outline how you would use a persistent sockets, and why it
would benefit you?


-Jason


On Mon, 2002-05-06 at 10:54, Markus Fischer wrote:
> Hi,
> 
> What do you mean with psocket() ?
> 
> - Markus
> 
> On Mon, May 06, 2002 at 09:39:23AM -0700, Tom Robinson wrote : 
> > I see you are right. Whereas although socket_last_error() (no argument) can be 
>viewed as a shortcut, it is actually a feature that cannot be duplicated in user 
>space because of the situation when socket_connect fails.
> > Next... how about psocket?
> > ...Tom
> > >This really is something that better belongs in user-space.
> > 
> 
> -- 
> Please always Cc to me when replying to me on the lists.
> GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
> "I'm not stupid, you know? :)" - Jani Taskinen



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

Re: [PHP-DEV] PHP 4.3 charter and release plan

[Jason Greene]

I would like to have the sockets extension polished and marked as stable
by 4.3, if you would like to add that to the list of changes.

-Jason
On Fri, 2002-05-03 at 00:17, Stig S. Bakken wrote:
> Hi,
> 
> I've volunteered to RM (release master, not /bin/rm) PHP 4.3.  This
> release will be synchronized with the public release of the PEAR
> (including PECL) infrastructure.
> 
> This time I'd like to try partitioning the work a bit by identifying the
> major changes and have one person sign up as responsible for each.
> 
> I will do the overall coordination and handle stuff that don't belong to
> these major changes.
> 
> Here's the list of major changes, and the person I would like to invite
> as responsible for that part of 4.3:
> 
> 1. New build system (Sascha)
> 
> 2. PHP Streams (Wez)
> 
> 3. Command-line SAPI installed by default (Edin)
> 
> 4. PEAR integration including PECL builder (Stig)
> 
> 5. MySQL changes (Zak)
> 
> 6. PostgreSQL changes (Yasuo)
> 
> 7. DOMXML changes? (Christian)
> 
> I'm not sure how significant the changes to mysql/pgsql/domxml are this
> time, this list was based on an overview of the NEWS file.
> 
> When someone has signed up for each major change, I want to get a
> feeling for how much work remains and make a rough internal release
> schedule.  The PHP_4_3_0 branch will be created when everyone says their
> stuff is ready for full testing.
> 
> Does this organization of the 4.3 release sound reasonable?
> 
>  - Stig
> 
> 
> -- 
> 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: Bug #17022: enhance socket_strerror(errno) tomakeerrno optional

[Jason Greene]

On Mon, 2002-05-06 at 00:31, Tom Robinson wrote:
> As a programmer fairly new to the PHP socket functions, there is a long enough list 
>of them already.
> For the most part, they match the C functions.
> socket_last_error() doesn't have a C equivalent, because of the difference in 
>environment.
> But in the PHP tradition, socket_last_error has two flavours, where the shortest one 
>is the one that can be used 90% of the time.

I understand that you were just looking for a shortcut, and your
suggestion does create a good shortcut for the way you you are using
socket_strerror(). The only reason I had a problem with the suggestion
is because it did not apply to all uses. I realize that you may use
socket_last_error()  with no sock arg 90% of the time, but use will vary
depending on application. 

> I personally would not want to see yet another function for socket_last_errstr() - 
>ever time a new function is added to the list, it makes the list a little bit longer 
>and a little bit less approachable for newcomers. My suggestion was to shorten up the 
>case where socket_strerror is used 90% of the time.

Ok, no problem, it was just an alternative suggested that would have
implemented the functionality you requested, except it would have
applied to all cases.  

I disagree with you that adding a shortcut to a function that was not
designed to behave in that manor is any easier to understand than a new
function that spells out the expected behavior.

I do agree that an extension can pollute its namespace with unnecessary
functions.

> I would extend my suggestion to say I would NOT want a new socket_last_errstr($sock) 
>function.
> It was just a simple little suggestion for a coding shortcut, with no new 
>functionality added, therefore not worthy of its own new function.

> Since no new functionality is added, I can (and did) code my own in PHP for use 
>after almost all my socket calls.
> ...Tom
> 

That is a good thing. An application should always have a custom error
wrapper, because the API will never provide all the desired
functionality within the lifespan of an application.

-Jason

> >I think the requested behavior does not belong in socket_strerror() 
> >simply because it would not match the primary and other use of
> >socket_last_error(). In other words, you would not be able to replace
> >the behavior of
> >
> >socket_strerror(socket_last_error($sock));
> >
> >What could be possible, would be to add something like
> >socket_last_errstr, which could then follow the same semantics of
> >socket_last_error. This would be a much more consistent.
> >i.e.
> >socket_last_errstr($sock);
> >socket_last_errstr();
> >
> >Would this be acceptable?
> 
> 
> 
> -- 
> 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: Bug #17022: enhance socket_strerror(errno) tomake errno optional

[Jason Greene]

Agreed,

This really is something that better belongs in user-space.

-Jason


On Mon, 2002-05-06 at 00:56, Markus Fischer wrote:
> Hi,
> 
> after thinking again I think it's best just not to touch this
> anyway. Let it be that one hast to call
> socket_strerror(socket_last_error()); There is really nothing
> wrong in writing this down that way. It's just getting much
> to write if you repeat your code everytime and to not use a
> generic error handler function in your application (and then
> it can't be a serious application IMO).
> 
> - Markus
> 
> On Sun, May 05, 2002 at 10:05:33PM -0500, Jason Greene wrote : 
> > I think the requested behavior does not belong in socket_strerror() 
> > simply because it would not match the primary and other use of
> > socket_last_error(). In other words, you would not be able to replace
> > the behavior of
> > 
> > socket_strerror(socket_last_error($sock));
> > 
> > What could be possible, would be to add something like
> > socket_last_errstr, which could then follow the same semantics of
> > socket_last_error. This would be a much more consistent.
> > 
> > i.e.
> > 
> > socket_last_errstr($sock);
> > socket_last_errstr();
> > 
> > Would this be acceptable?
> > 
> > -Jason
> > 
> > 
> > 
> > On Sun, 2002-05-05 at 16:33, Markus Fischer wrote:
> > > Hi,
> > > 
> > > technically this isn't a problem at all. I'm just pondering
> > > .. socket_strerror() is nothing better then a call to
> > > strerror().
> > > 
> > > If we one day decide to introduce a generic strerror()
> > > function to PHP it can't automagically fetch the last socket
> > > error of course ... that's the only fear/ojections I have.
> > > 
> > > - Markus
> > > 
> > > On Sun, May 05, 2002 at 09:23:23PM -, [EMAIL PROTECTED] wrote : 
> > > > From: [EMAIL PROTECTED]
> > > > Operating system: any
> > > > PHP version:  4.2.0
> > > > PHP Bug Type: Sockets related
> > > > Bug description:  enhance socket_strerror(errno) to make errno optional
> > > > 
> > > > socket_last_error(socket) was recently enhanced to make the socket
> > > > optional.
> > > > 
> > > > How about doing the same for the error number argument to
> > > > socket_strerror() ?
> > > > 
> > > > So instead of writing:
> > > >   die (socket_strerror(socket_last_error())
> > > > I can just write:
> > > >   die (socket_strerror())
> > > > 
> > > > ...Tom Robinson
> > > > 
> > > > 
> > > > -- 
> > > > Edit bug report at http://bugs.php.net/?id=17022&edit=1
> > > > -- 
> > > > Fixed in CVS:http://bugs.php.net/fix.php?id=17022&r=fixedcvs
> > > > Fixed in release:http://bugs.php.net/fix.php?id=17022&r=alreadyfixed
> > > > Need backtrace:  http://bugs.php.net/fix.php?id=17022&r=needtrace
> > > > Try newer version:   http://bugs.php.net/fix.php?id=17022&r=oldversion
> > > > Not developer issue: http://bugs.php.net/fix.php?id=17022&r=support
> > > > Expected behavior:   http://bugs.php.net/fix.php?id=17022&r=notwrong
> > > > Not enough info: http://bugs.php.net/fix.php?id=17022&r=notenoughinfo
> > > > Submitted twice: http://bugs.php.net/fix.php?id=17022&r=submittedtwice
> > > > register_globals:http://bugs.php.net/fix.php?id=17022&r=globals
> > > 
> > > -- 
> > > Please always Cc to me when replying to me on the lists.
> > > GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
> > > "I'm not stupid, you know? :)" - Jani Taskinen
> > > 
> > > -- 
> > > PHP Development Mailing List <http://www.php.net/>
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > > 
> > 
> 
> -- 
> Please always Cc to me when replying to me on the lists.
> GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
> "I'm not stupid, you know? :)" - Jani Taskinen
> 
> -- 
> 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: Bug #17022: enhance socket_strerror(errno) tomake errno optional

[Jason Greene]

I think the requested behavior does not belong in socket_strerror() 
simply because it would not match the primary and other use of
socket_last_error(). In other words, you would not be able to replace
the behavior of

socket_strerror(socket_last_error($sock));

What could be possible, would be to add something like
socket_last_errstr, which could then follow the same semantics of
socket_last_error. This would be a much more consistent.

i.e.

socket_last_errstr($sock);
socket_last_errstr();

Would this be acceptable?

-Jason



On Sun, 2002-05-05 at 16:33, Markus Fischer wrote:
> Hi,
> 
> technically this isn't a problem at all. I'm just pondering
> .. socket_strerror() is nothing better then a call to
> strerror().
> 
> If we one day decide to introduce a generic strerror()
> function to PHP it can't automagically fetch the last socket
> error of course ... that's the only fear/ojections I have.
> 
> - Markus
> 
> On Sun, May 05, 2002 at 09:23:23PM -, [EMAIL PROTECTED] wrote : 
> > From: [EMAIL PROTECTED]
> > Operating system: any
> > PHP version:  4.2.0
> > PHP Bug Type: Sockets related
> > Bug description:  enhance socket_strerror(errno) to make errno optional
> > 
> > socket_last_error(socket) was recently enhanced to make the socket
> > optional.
> > 
> > How about doing the same for the error number argument to
> > socket_strerror() ?
> > 
> > So instead of writing:
> >   die (socket_strerror(socket_last_error())
> > I can just write:
> >   die (socket_strerror())
> > 
> > ...Tom Robinson
> > 
> > 
> > -- 
> > Edit bug report at http://bugs.php.net/?id=17022&edit=1
> > -- 
> > Fixed in CVS:http://bugs.php.net/fix.php?id=17022&r=fixedcvs
> > Fixed in release:http://bugs.php.net/fix.php?id=17022&r=alreadyfixed
> > Need backtrace:  http://bugs.php.net/fix.php?id=17022&r=needtrace
> > Try newer version:   http://bugs.php.net/fix.php?id=17022&r=oldversion
> > Not developer issue: http://bugs.php.net/fix.php?id=17022&r=support
> > Expected behavior:   http://bugs.php.net/fix.php?id=17022&r=notwrong
> > Not enough info: http://bugs.php.net/fix.php?id=17022&r=notenoughinfo
> > Submitted twice: http://bugs.php.net/fix.php?id=17022&r=submittedtwice
> > register_globals:http://bugs.php.net/fix.php?id=17022&r=globals
> 
> -- 
> Please always Cc to me when replying to me on the lists.
> GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
> "I'm not stupid, you know? :)" - Jani Taskinen
> 
> -- 
> 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] sockets

[Jason Greene]

On Mon, 2002-04-29 at 11:14, Steve Meyers wrote:
> On Sun, 2002-04-28 at 22:43, Jason Greene wrote:
> > In the case of a socket you are selecting on has errored, the socket
> > will show up as readable. You then can perform a socket_read/recv, and
> > you should receive NULL (errored socket), then you can call
> > socket_last_error to receive the errno.
> > 
> Unless I'm just a really bad coder and have no idea what I'm doing, this
> won't help.  I tried using socket_last_error, but it returns the same
> error code whether the socket has no data waiting (remember this is a
> non-blocking socket) or if the socket has died.  I can only tell if it
> is dead by writing to the socket.
> 
> What I'd like to do is just find out if the socket is still alive.

You have to call read/recv or write/send before you call last_error.

You should get FALSE from the return of your read/recv, and
socket_last_error should contain EAGAIN if no data is avail on a
non-blocking socket, ECONRESET if the connection was reset by the
peer(etc..etc..), or you would get "" from the return of the read (0
bytes from recv) which would indicate EOF.

-Jason



> 
> -- 
> 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] socket_create() doesn't expose error if one occurs[CVS HEAD]

[Jason Greene]

The patch looks good to me,  go ahead and apply it.


Thanks,
-Jason

On Mon, 2002-04-29 at 04:02, Markus Fischer wrote:
> Hi,
> 
> attached is the patch I intend to commit later this day:
> 
> - Stores last errno in a module global implicitely
> - Sets global last error explicitely for socket_select() and
>   socket_create()
> - Modified socket_last_error() to return global modules last
>   error if no socket resource is given
> - Added a couple of more E_WARNING messages in case something
>   goes foobar so the user isn't left alone in the dark.
> 
> regards,
> - Markus
> 
> On Sun, Apr 28, 2002 at 10:53:42PM -0500, Jason Greene wrote : 
> > This was something I was planning on adding, but it was not applied to
> > the 4.2.0 branch, because it introduces a feature enhancement (storing a
> > global last error) and not a bug fix. It is a very simple enhance, I
> > just have not had the time to work on it yet.
> > 
> > -Jason
> 
> -- 
> Please always Cc to me when replying to me on the lists.
> GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
> "Mind if I MFH ?" "What QA did you do on it?" "the usual?" "ah... none :)"
> 
> 

> ? sockets.diff
> Index: php_sockets.h
> ===
> RCS file: /repository/php4/ext/sockets/php_sockets.h,v
> retrieving revision 1.22
> diff -u -r1.22 php_sockets.h
> --- php_sockets.h 6 Mar 2002 20:19:09 -   1.22
> +++ php_sockets.h 29 Apr 2002 08:56:25 -
> @@ -102,12 +102,14 @@
>  int accept_connect(php_socket *in_sock, php_socket **new_sock, struct sockaddr *la 
>TSRMLS_DC);
>  int php_read(int bsd_socket, void *buf, int maxlen);
>  
> +ZEND_BEGIN_MODULE_GLOBALS(sockets)
> +int last_error;
> +ZEND_END_MODULE_GLOBALS(sockets)
> +
>  #ifdef ZTS
> -#define SOCKETSG(v) (sockets_globals->v)
> -#define SOCKETSLS_FETCH() php_sockets_globals *sockets_globals = 
>ts_resource(sockets_globals_id)
> +#define SOCKETS_G(v) TSRMG(sockets_globals_id, zend_sockets_globals *, v)
>  #else
> -#define SOCKETSG(v) (sockets_globals.v)
> -#define SOCKETSLS_FETCH()
> +#define SOCKETS_G(v) (sockets_globals.v)
>  #endif
>  
>  #else
> Index: sockets.c
> ===
> RCS file: /repository/php4/ext/sockets/sockets.c,v
> retrieving revision 1.98
> diff -u -r1.98 sockets.c
> --- sockets.c 11 Mar 2002 01:24:42 -  1.98
> +++ sockets.c 29 Apr 2002 08:56:25 -
> @@ -62,12 +62,7 @@
>  # define IS_INVALID_SOCKET(a)(a->bsd_socket == INVALID_SOCKET)
>  #endif
>  
> -#ifdef ZTS
> -int sockets_globals_id;
> -#else
> -php_sockets_globals sockets_globals;
> -#endif
> -
> +ZEND_DECLARE_MODULE_GLOBALS(sockets)
>  
>  #ifndef MSG_WAITALL
>  #ifdef LINUX
> @@ -90,7 +85,9 @@
>  #define PHP_BINARY_READ 0x0002
>  
>  #define PHP_SOCKET_ERROR(socket,msg,errn)socket->error = errn;   \
> -
> php_error(E_WARNING, "%s() %s [%d]: %s", get_active_function_name(TSRMLS_C), msg, 
>errn, php_strerror(errn))
> +
> SOCKETS_G(last_error) = errn; \
> +
> php_error(E_WARNING, "%s() %s [%d]: %s", \
> +
>   get_active_function_name(TSRMLS_C), msg, errn, php_strerror(errn))
>  
>  static int le_iov;
>  #define le_iov_name "Socket I/O vector"
> @@ -374,12 +371,20 @@
>   return 1;
>  }
>   
> +
> +static void php_sockets_init_globals(zend_sockets_globals *sockets_globals 
>TSRMLS_DC)
> +{
> + sockets_globals->last_error = 0;
> +}
> +
>  /* {{{ PHP_MINIT_FUNCTION
>   */
>  PHP_MINIT_FUNCTION(sockets)
>  {
>   struct protoent *pe;
>  
> + ZEND_INIT_MODULE_GLOBALS(sockets, php_sockets_init_globals, NULL);
> +
>   le_socket   = zend_register_list_destructors_ex(destroy_socket, NULL, 
>le_socket_name, module_number);
>   le_iov  = zend_register_list_destructors_ex(destroy_iovec,  NULL, 
>le_iov_name, module_number);
>  
> @@ -526,6 +531,7 @@
>   retval = select(max_fd+1, &rfds, &wfds, &efds, tv_p);
>  
>   if (retval == -1) {
> + SOCKETS_G(last_error) = errno;
>   php_error(E_WARNING, "%s() %s [%d]: %s", 
&

Re: [PHP-DEV] sockets

[Jason Greene]

Actually, I just reread your response again.

socket_select returns NULL on a SELECT error, this does not mean that it
will return an error on a socket IN the set you are selecting on that
has errored.

In the case of a socket you are selecting on has errored, the socket
will show up as readable. You then can perform a socket_read/recv, and
you should receive NULL (errored socket), then you can call
socket_last_error to receive the errno.

If the socket has hit an eof your socket_read would have returned a 0
len string, socket_recv would return 0 bytes, and socket_select would
have shown the socket to be readable.

All in all, socket_get_status is designed for the abstracted interface
fsockopen, and not for the lowlevel socket. The way it does this is by
performing the steps suggested by J. Smith and myself above.

Also, if you want to just check for an error on a socket, and you don't
want to read your data (which you should rarely have to do) there is a
MSG_PEEK option you can pass socket_recv that will allow you to look
ahead and not clear.

Thanks,
-Jason





 Sun, 2002-04-28 at 22:56, Jason Greene wrote:
> On Sun, 2002-04-28 at 18:31, J Smith wrote:
> > 
> > One way to find which socket has died, if any, is to loop through each 
> > socket in the three sets (read/write/exceptions) and do a select() on each 
> > one to see if you can read with a timeout of 0. (The bad one being the one 
> > where select() returns -1, I think.)
> > 
> > J
> > 
> 
> socket_select returns NULL on error. 
> 
> -Jason
> > 
> > Steve Meyers wrote:
> > 
> > > There's only one thing it's missing -- the equivalent of
> > > socket_get_status(), which is not part of the extension, despite the name.
> > > If I set my socket to nonblocking, the only way to tell if it has died is
> > > to try to write to it, which isn't always a desirable thing to do :)
> > > 
> > > Unless there's another way that I just don't understand.
> > > 
> > 
> > 
> > -- 
> > 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] sockets

[Jason Greene]

True,

Threading support would be a powerful feature to php, but it is not
likely to happen anytime soon, due to current design issues with doing
it, and the fact that it would take someone who was really really
focused on adding this functionality (it would be alot of work).

Now with that said, you should be able to handle everything you need to
do with I/O multiplexing, or prefork. If  you absolutely need the
performance of threads, and your task is complex enough, you may want to
look at building a simple multi-threaded c client lib, and then building
a php wrapper over it.

Also, php has a little known functionality called "ticks" that allows
you to have an external function called between X number of opcodes.

Hope this helps,
-Jason


On Fri, 2002-04-26 at 11:05, Dan Hardiker wrote:
> The only feature which would be useful towards this module is threading. If
> PHP were able to thread it could handle multiple incoming sockets and
> neglegate the need for IPC between child processes (where PCNTL has been
> used) as it could all be handled by a common parent with shared (not
> copied) variables.
> 
> Just my 2p's worth
> 
> -- 
> Dan Hardiker [[EMAIL PROTECTED]]
> ADAM Software & Systems Engineer
> First Creative Ltd
> 
> >
> > I've been using it since the first API revision and it's been working
> > fine  for me. (Up to and including the latest API revision.) As far as
> > I'm  concerned, it's getting pretty close to losing the experimental
> > tag.  (Perhaps by PHP 4.3.x or so, barring any glarring problems that
> > I've not  encountered.)
> >
> > J
> >
> >
> > Markus Fischer wrote:
> >
> >> Hi,
> >>
> >> Simple when enough people have tested it and it reaches the
> >> consensus that it's mature enough for being called stable
> >> (api doesn't change anymore, more testers, you name it).
> >>
> >> - Markus
> >>
> >> On Thu, Apr 25, 2002 at 07:46:30PM +0200, Michael Virnstein wrote :
> >>> Hi,
> >>>
> >>> as i could read in the manual, the socket functions are completely
> >>> experimental.
> >>> When do you think the API gets final and won't change
> >>> anymore. Any comments on this are welcome.
> >>>
> >>> Michael
> >>>
> >
> >
> > --
> > 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] sockets

[Jason Greene]

On Sun, 2002-04-28 at 18:31, J Smith wrote:
> 
> One way to find which socket has died, if any, is to loop through each 
> socket in the three sets (read/write/exceptions) and do a select() on each 
> one to see if you can read with a timeout of 0. (The bad one being the one 
> where select() returns -1, I think.)
> 
> J
> 

socket_select returns NULL on error. 

-Jason
> 
> Steve Meyers wrote:
> 
> > There's only one thing it's missing -- the equivalent of
> > socket_get_status(), which is not part of the extension, despite the name.
> > If I set my socket to nonblocking, the only way to tell if it has died is
> > to try to write to it, which isn't always a desirable thing to do :)
> > 
> > Unless there's another way that I just don't understand.
> > 
> 
> 
> -- 
> 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] sockets

[Jason Greene]

I was hoping on tagging this extension as stable by the next PHP
release. In order to do this, everyone needs to feel comfortable with
the extension.

Thanks,
-Jason

On Thu, 2002-04-25 at 12:46, Michael Virnstein wrote:
> Hi,
> 
> as i could read in the manual, the socket functions are completely
> experimental.
> When do you think the API gets final and won't change
> anymore. Any comments on this are welcome.
> 
> Michael
> 
> 
> 
> -- 
> 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] socket_create() doesn't expose error if one occurs[CVS HEAD]

[Jason Greene]

This was something I was planning on adding, but it was not applied to
the 4.2.0 branch, because it introduces a feature enhancement (storing a
global last error) and not a bug fix. It is a very simple enhance, I
just have not had the time to work on it yet.

-Jason



On Sat, 2002-04-27 at 07:22, Markus Fischer wrote:
> Hi,
> 
> socket_create() doesn't expose an error if one occurs when
> creating a new socket with socket(). The current code is:
> 
> [...]
> php_sock->bsd_socket = socket(arg1, arg2, arg3);
> php_sock->type = arg1;
> 
> if (IS_INVALID_SOCKET(php_sock)) {
> efree(php_sock);
> RETURN_FALSE;
> }
> 
> ZEND_REGISTER_RESOURCE(return_value, php_sock, le_socket);
> }
> 
> This logic silently hides the error if we encounter one
> during socket creating.
> 
> 
> Since the current socket error reporting facility only
> operates with a valid socket resource context we have a
> limitation here because obviously there's no valid socket
> resource context here (false is returned and we don't have
> the socket resource yet).
> 
> 
> Suggestion:
> Introduce a (per thread) global variable which always stores
> the error message of the last socket function which failed
> and teach socket_last_error() to return this value if no
> resource is passed to it, e.g.:
> 
> if (false == (socket_create(...))) {
> echo "Failed, reason:", socket_strerror(socket_last_error()), "\n";
> [...]
> }
> 
> To be consistent with the other socket_*() functions I also
> suggest emitting an E_WARNING message if it fails (basically
> all other functions have been rewritten this way).
> 
> I haven't included a patch because it's rather trivial.
> 
> Any objections or better suggestions how to handle this?
> 
> - Markus
> 
> -- 
> Please always Cc to me when replying to me on the lists.
> GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
> "Mind if I MFH ?" "What QA did you do on it?" "the usual?" "ah... none :)"
> 
> -- 
> 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] Unsigned Right(Maybee Left) Shift [Again]

[Jason Greene]

Well it wouldn't be changing the behavior of the heredoc operator, it
would only be interpreted differently depending on the situation.

Technically, I think it could be done without ambiguities.

-Jason


On Thu, 2002-04-04 at 09:57, Marc Boeren wrote:
> > Reasons expressed against it
> > 
> > It is the heredoc operator
> 
> > however, I need a tie breaker. 
> 
> Is the heredoc operator not a tie breaker (or decision maker) on it's own?
> 
> No need to change the behaviour of an existing operator just for
> consistency, is there?
> 
> Cheerio, Marc.
-- 
Jason T. Greene
Internet Software Engineer

<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]>

Use PHP: http://www.php.net



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

[PHP-DEV] Unsigned Right(Maybee Left) Shift [Again]

[Jason Greene]

So far, after posting to php-general and php-dev about whether or not we
should add a <<< operator to match the >>> operator, I have received 4
total responses.

2 for it
2 against it

Reasons expressed for it

Consistent
Doesn't hurt anything

Reasons expressed against it

It is the heredoc operator
Not really needed
Could be confusing


I am personally neutral, because I don't think it matters either way;
however, I need a tie breaker. 

Anyone want to help me out here?

Thanks





-- 
Jason T. Greene
Internet Software Engineer

<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]>

Use PHP: http://www.php.net



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

Re: [PHP-DEV] webserver in PHP

[Jason Greene]

On Mon, 2002-04-01 at 10:58, Daniel Lorch wrote:

> I am writing a "server/daemon framework" which should eventually allow
> PHP developers to quickly create a server. You should look at the
> "quoted.php" to see how easy this actually is. The framework does all
> the dirty work in the background (forking off new children, managing
> connections ..) and this is exactly the point where I have a problem:


Neat project!
> how do I manage my child processes? My workaround is
> to pcntl_signal(SIGCHLD, SIG_IGN); , but I actually want to keep track
> of my childern (to limit the number of connections). Whenever I get a
> SIGCHLD from a child process, how the hell should I know what PID
> it came from? Should I just keep a list of processes and poll them
> from time to time?

There are many methods to accomplish child management. One method does
involve polling.

A better way to do the method that you are trying to to do is to set a
signal handler for SIGCHLD that waits on a pid of -1 (This means grab
any child with a status change)

ex.
R
function child_wait($signo) {
$pid=waitpid(-1, $status, $options);
if (pcntl_wifexited($status)) print "$pid exited!\n";
}

pcntl_signal(SIGCHLD, "child_wait");

This will effectively prevent zombies. 

>
> there is a working demo for the next couple of hours (until I switch
> off the machine):
> 
>   http://212.254.248.130/

Neat!
> 
> Daniel Lorch
> 

-Jason


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

[PHP-DEV] Unsigned Right Shift Sould there be a matching left shift?

[Jason Greene]

Hello everyone, 

Andi and I have been talking offline regarding my unsigned right shift
operator patch. We have decided to implement this change in ZE2;
however, there is one thing left to be resolved before the functionality
can be added. 

Currently the Unsigned Right Shift patch implements 2 new operators: 
>>>  (Unsigned Shift) 
>>>= (Unsigned Shift Assign) 

In my initial patch I did not include the equivalent left shift
operators because sign only affects a right shift. However, this does
introduce a consistency problem, and so the question is should we
implement <<< and <<<= and have them just be aliases to << and <<=? 

Thanks,
-Jason





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

Re: [PHP-DEV] poll (2) - portability/alternatives

[Jason Greene]

If a socket is added to readfds select will return if the follow occurs:

error on the socket
EOF on the socket 
data on the socket

Therefore, you should be able to call select on the socket (adding a
timeout for sanity) and if it returns call read/recv. If the return
value is 0 an EOF has occurred, if -1 an error occurred.

The worst that can happen in this scenario is that you get data, this
however can be resolved by using the MSG_PEEK option to recv, then you
don't remove the data from the buffer.

-Jason

On Mon, 2002-03-18 at 16:39, Wez Furlong wrote:
> Theres a bug in the DB where feof($sock) will not detect
> a timed-out connection.
> 
> I have a fix which uses poll(2) if available to check if
> the socket has hungup.
> 
> If poll(2) is not present, it will try to read a chunk
> of data; if that times out or sets the eof indicator,
> then an EOF is returned.
> 
> Does anyone know just how portable poll(2) is, and if
> there is an alternative portable technique to check if
> the sock is still connected?
> My man page says that libc emulates poll(2) in older
> linux kernels using select(); can anyone point me to
> some code that does this using select()?
> 
> --Wez.
> 
> 
> -- 
> 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] Unsigned Right Shift Operator

[Jason Greene]

Note: there is a slight WS fix in this patch. (A couple of lines had
trailing spaces)

On Sun, 2002-03-17 at 23:22, Jason Greene wrote:
> After a short discussion on the zend-engine-2 list about handling
> unsigned values I decided to write a quick patch (Attached) that adds an
> unsigned right shift operator, and an unsigned right shift assign
> operator (Similar to Java).
> 
> The following code/output displays the difference:
> 
> Code:
> 
>  
> $signed = 1 << 31 >> 31;
> $unsigned = 1 << 31 >>> 31;
> 
> print "Signed: $signed\n";
> print "Unsigned: $unsigned\n";
> 
> ?>
> 
> Output:
> 
> Signed: -1
> Unsigned: 1
> 
> 
> 
>


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

[PHP-DEV] [PATCH] Unsigned Right Shift Operator

[Jason Greene]

After a short discussion on the zend-engine-2 list about handling
unsigned values I decided to write a quick patch (Attached) that adds an
unsigned right shift operator, and an unsigned right shift assign
operator (Similar to Java).

The following code/output displays the difference:

Code:

> 31;
$unsigned = 1 << 31 >>> 31;

print "Signed: $signed\n";
print "Unsigned: $unsigned\n";

?>

Output:

Signed: -1
Unsigned: 1







Index: zend_compile.h
===
RCS file: /repository/Zend/zend_compile.h,v
retrieving revision 1.141
diff -u -r1.141 zend_compile.h
--- zend_compile.h  10 Feb 2002 12:52:45 -  1.141
+++ zend_compile.h  18 Mar 2002 05:12:02 -
@@ -396,6 +396,7 @@
 #define ZEND_MOD   5
 #define ZEND_SL6
 #define ZEND_SR7
+#define ZEND_USR   107
 #define ZEND_CONCAT8
 #define ZEND_BW_OR 9
 #define ZEND_BW_AND10
@@ -419,6 +420,7 @@
 #define ZEND_ASSIGN_MOD27
 #define ZEND_ASSIGN_SL 28
 #define ZEND_ASSIGN_SR 29
+#define ZEND_ASSIGN_USR108
 #define ZEND_ASSIGN_CONCAT 30
 #define ZEND_ASSIGN_BW_OR  31
 #define ZEND_ASSIGN_BW_AND 32
@@ -521,7 +523,6 @@
 #define ZEND_TICKS 105
 
 #define ZEND_SEND_VAR_NO_REF   106
-
 /* end of block */
 
 
Index: zend_execute.c
===
RCS file: /repository/Zend/zend_execute.c,v
retrieving revision 1.293
diff -u -r1.293 zend_execute.c
--- zend_execute.c  6 Jan 2002 15:21:09 -   1.293
+++ zend_execute.c  18 Mar 2002 05:12:08 -
@@ -1077,6 +1077,9 @@
case ZEND_SR:
EG(binary_op) = shift_right_function;
goto binary_op_addr;
+   case ZEND_USR:
+   EG(binary_op) = ushift_right_function;
+   goto binary_op_addr;
case ZEND_CONCAT:
EG(binary_op) = concat_function;
goto binary_op_addr;
@@ -1144,6 +1147,9 @@
goto binary_assign_op_addr;
case ZEND_ASSIGN_SR:
EG(binary_op) = shift_right_function;
+   goto binary_assign_op_addr;
+   case ZEND_ASSIGN_USR:
+   EG(binary_op) = ushift_right_function;
goto binary_assign_op_addr;
case ZEND_ASSIGN_CONCAT:
EG(binary_op) = concat_function;
Index: zend_language_parser.y
===
RCS file: /repository/Zend/zend_language_parser.y,v
retrieving revision 1.17
diff -u -r1.17 zend_language_parser.y
--- zend_language_parser.y  19 Jan 2002 10:28:26 -  1.17
+++ zend_language_parser.y  18 Mar 2002 05:12:10 -
@@ -53,7 +53,7 @@
 %left T_LOGICAL_XOR
 %left T_LOGICAL_AND
 %right T_PRINT
-%left '=' T_PLUS_EQUAL T_MINUS_EQUAL T_MUL_EQUAL T_DIV_EQUAL T_CONCAT_EQUAL 
T_MOD_EQUAL T_AND_EQUAL T_OR_EQUAL T_XOR_EQUAL T_SL_EQUAL T_SR_EQUAL
+%left '=' T_PLUS_EQUAL T_MINUS_EQUAL T_MUL_EQUAL T_DIV_EQUAL T_CONCAT_EQUAL 
+T_MOD_EQUAL T_AND_EQUAL T_OR_EQUAL T_XOR_EQUAL T_SL_EQUAL T_SR_EQUAL T_USR_EQUAL
 %left '?' ':'
 %left T_BOOLEAN_OR
 %left T_BOOLEAN_AND
@@ -62,7 +62,7 @@
 %left '&'
 %nonassoc T_IS_EQUAL T_IS_NOT_EQUAL T_IS_IDENTICAL T_IS_NOT_IDENTICAL
 %nonassoc '<' T_IS_SMALLER_OR_EQUAL '>' T_IS_GREATER_OR_EQUAL
-%left T_SL T_SR
+%left T_SL T_SR T_USR
 %left '+' '-' '.'
 %left '*' '/' '%'
 %right '!' '~' T_INC T_DEC T_INT_CAST T_DOUBLE_CAST T_STRING_CAST T_ARRAY_CAST 
T_OBJECT_CAST T_BOOL_CAST T_UNSET_CAST '@'
@@ -430,8 +430,9 @@
|   cvar T_AND_EQUAL expr   { 
zend_do_end_variable_parse(BP_VAR_RW, 0 TSRMLS_CC); 
zend_do_binary_assign_op(ZEND_ASSIGN_BW_AND, &$$, &$1, &$3 TSRMLS_CC); }
|   cvar T_OR_EQUAL expr{ 
zend_do_end_variable_parse(BP_VAR_RW, 0 TSRMLS_CC); 
zend_do_binary_assign_op(ZEND_ASSIGN_BW_OR, &$$, &$1, &$3 TSRMLS_CC); }
|   cvar T_XOR_EQUAL expr   { 
zend_do_end_variable_parse(BP_VAR_RW, 0 TSRMLS_CC); 
zend_do_binary_assign_op(ZEND_ASSIGN_BW_XOR, &$$, &$1, &$3 TSRMLS_CC); }
-   |   cvar T_SL_EQUAL expr{ zend_do_end_variable_parse(BP_VAR_RW, 0 
TSRMLS_CC); zend_do_binary_assign_op(ZEND_ASSIGN_SL, &$$, &$1, &$3 TSRMLS_CC); } 
-   |   cvar T_SR_EQUAL expr{ zend_do_end_v

[PHP-DEV] Versioning

[Jason Greene]

Doesn't it make more since to release a version where one of the numbers
is a bugfix number?

ex currently we have:  [ Huge.Major.Minor ]

and then when bugs are fixed they are: [ Huge.Major.Minor pl Bugfix ]

Hardly ever is a version released without a bugfix of some sort. 

I have seen the argument that we should follow: [ Major.Minor.Bug ].
Which i think is do-able if you alow minor to be larger than 1 digit.
ex PHP 5.12.1. If this is not desired it could follow a 4 digit
numbering system (Which is pseudo what we have today) except that
release version would always include the pl number. ex:

4.2.1.RC1

bugs fixed

4.2.1.RC2

bugs fixed / release

4.2.1.0

Then bugs are fixed

4.2.1.1

More bugs are fixed

4.2.1.2



Opinions?

-Jason







On Thu, 2002-03-14 at 08:15, Zeev Suraski wrote:
> zeev  Thu Mar 14 09:15:26 2002 EDT
> 
>   Modified files:  
> /php4 configure.in 
> /php4/mainphp_version.h 
>   Log:
>   Good suggestion, but I'm not sure we want to start receiving bug
>   reports with that version
>   
>   
> Index: php4/configure.in
> diff -u php4/configure.in:1.317 php4/configure.in:1.318
> --- php4/configure.in:1.317   Thu Mar 14 09:00:03 2002
> +++ php4/configure.in Thu Mar 14 09:15:24 2002
> @@ -1,4 +1,4 @@
> -dnl ## $Id: configure.in,v 1.317 2002/03/14 14:00:03 sterling Exp $ -*- sh -*-
> +dnl ## $Id: configure.in,v 1.318 2002/03/14 14:15:24 zeev Exp $ -*- sh -*-
>  dnl ## Process this file with autoconf to produce a configure script.
>  
>  divert(1)
> @@ -37,7 +37,7 @@
>  AC_CANONICAL_HOST
>  AC_CONFIG_HEADER(main/php_config.h)
>  
> -VERSION="4.STFU"
> +VERSION="4.2.1-dev"
>  
>  dnl Define where extension directories are located in the configure context
>  AC_DEFUN(PHP_EXT_BUILDDIR,[ext/$1])dnl
> Index: php4/main/php_version.h
> diff -u php4/main/php_version.h:1.57 php4/main/php_version.h:1.58
> --- php4/main/php_version.h:1.57  Thu Mar 14 09:00:04 2002
> +++ php4/main/php_version.h   Thu Mar 14 09:15:26 2002
> @@ -1,3 +1,3 @@
>  /* automatically generated by configure */
>  /* edit configure.in to change version number */
> -#define PHP_VERSION "4.STFU"
> +#define PHP_VERSION "4.2.1-dev"
> 
> 
> 
> -- 
> 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] Is credits_ext.h still being updated?

[Jason Greene]

I fixed the process so that it should build correctly now. All that is
needed is a cronjob to run it, test for differences, and then commit
them.

-Jason

On Wed, 2002-03-13 at 09:24, Hartmut Holzgraefe wrote:
> Jason Greene wrote:
> > Nevermind, for some reason I thought this was automated.
> 
> well, there was a plan to do so way back, but somehow
> it got lost on the way ...
> 
> 
> 
> -- 
> Hartmut Holzgraefe  [EMAIL PROTECTED]  http://www.six.de  +49-711-99091-77
> 
> Wir stellen für Sie aus auf der CeBIT 2002 und freuen uns
> in Halle 6 auf Ihren Besuch am Stand H 18
> 
-- 
Jason T. Greene
Internet Software Engineer

<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]>

Use PHP: http://www.php.net



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

Re: [PHP-DEV] Is credits_ext.h still being updated?

[Jason Greene]

Nevermind, for some reason I thought this was automated.


On Tue, 2002-03-12 at 18:01, Jason Greene wrote:
> I added myself to the Sockets Extension a few months ago, and it has
> never propagated.
> 
> -Jason
> 
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
-- 
Jason T. Greene
Internet Software Engineer

<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]>

Use PHP: http://www.php.net



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

[PHP-DEV] Is credits_ext.h still being updated?

[Jason Greene]

I added myself to the Sockets Extension a few months ago, and it has
never propagated.

-Jason



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

[PHP-DEV] Sockets: new socket_select() example

[Jason Greene]

Due to popular request, here is an example of the new socket_select():
NOTE: ***This code does not do any error handling***





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

Re: [PHP-DEV] Socket Rework Complete

[Jason Greene]

I would be happy to help in any way possible.
Your source wasn't attached though. Would you like an example?
(That or you can resend your source)

-Jason


On Fri, 2002-03-08 at 13:10, J Smith wrote:
> 
> Speaking of the FD_* macros and such, I'm trying to visualize how to 
> re-write some code that I have that relies on the socket_fd_* functions. If 
> you get the chance, could you look over this simplified version of what I'm 
> doing and point me towards the proper direction to get it working with the 
> new API. I want to have this stuff ready when PHP 4.2 or 4.3 come out, and 
> seeing as you're the one closest to the sockets extension, I thought you 
> could give me some pointers as to how it would work with the abscence of 
> the sockets_fd_* functions. (I'm a little confused what to do without the 
> FD_* stuff. This could make for a good example in the documentation, 
> anyways, if it works as hoped.)
> 
> Attached is the stripped-down source.
> 
> J
> 
> 
> Jason Greene wrote:
> 
> > 
> > The correct behavior that is consistent with the API follows(that I am
> > planning):
> > Set retval of socket_select() to be the number of file descriptors
> > available. If error occurs set to false.
> > 
> > Using the c-api one commonly writes code like this
> > --
> > Error on an actual error or no sockets available:
> > 
> > ret=select(rfds, NULL, NULL, &tv);
> > if (ret < 0)
> >error_func();
> > 
> > Error differently:
> > 
> > ret=select(rfds, NULL, NULL, &tv);
> > if (ret == -1)
> > error_sys();
> > if (ret == 0)
> > error_noavail();
> > 
> > 
> > The equiv in php using false:
> > --
> > 
> > Error on an actual error or no sockets available:
> > 
> > $ret=socket_select($rfds, NULL, NULL, 1);
> > if (ret == 0)
> >error_func();
> > 
> > Error differently:
> > 
> > $ret=socket_select($rfds, NULL, NULL, 1);
> > if (ret === FALSE)
> >error_sys();
> > if (ret === 0)
> >error_noavail();
> > 
> > 
> >> According to the man file:
> >>
> > 
> >> (Although without the functions equivalent
> >> to the FD_* macros', the extension as a whole is getting pretty far
> >> removed from the standard sockets library as it is.)
> >> 
> >> J
> > 
> > Yes, the goal is to follow a more php like behavior. Those who follow
> > the C-API will have some slight adjusting to, but the beauty of the
> > high-level language is that we can automate and simplify the
> > functionality.
> > 
> > This also makes it easier for people who don't know C to pickup the
> > functionality.
> > 
> > -Jason
> >> --
> >> 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
> 
-- 
Jason T. Greene
Internet Software Engineer

<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]>

Use PHP: http://www.php.net



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

Re: [PHP-DEV] Socket Rework Complete

[Jason Greene]

On Fri, 2002-03-08 at 11:02, Markus Fischer wrote:
> On Fri, Mar 08, 2002 at 11:22:08AM -0500, J Smith wrote : 
> > I'm thinking that this functionality is a bit too far removed from the 
> > standard select() call [...]
> 
> I agree on that. Let there be an int return from
> socket_select(). You still can return 'false' on error
> condition.

Yes, that is the behavior I was planning.
The only problem is that the current function returns -1 instead of
FALSE.

-Jason

> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
-- 
Jason T. Greene
Internet Software Engineer

<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]>

Use PHP: http://www.php.net



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

Re: [PHP-DEV] Socket Rework Complete

[Jason Greene]

On Fri, 2002-03-08 at 10:22, J Smith wrote:
> 
> I don't think that's a hot idea. The return value of select() is an int for 
> reason and not merely true or false. It's supposed to return the number of 
> file descriptors that are ready for reading, writing or exceptions. 

The correct behavior that is consistent with the API follows(that I am
planning):
Set retval of socket_select() to be the number of file descriptors
available. If error occurs set to false.

Using the c-api one commonly writes code like this
--
Error on an actual error or no sockets available:

ret=select(rfds, NULL, NULL, &tv);
if (ret < 0)
   error_func();

Error differently:

ret=select(rfds, NULL, NULL, &tv);
if (ret == -1)
error_sys();
if (ret == 0)
error_noavail();


The equiv in php using false:
--

Error on an actual error or no sockets available:

$ret=socket_select($rfds, NULL, NULL, 1);
if (ret == 0)
   error_func();

Error differently:

$ret=socket_select($rfds, NULL, NULL, 1);
if (ret === FALSE)
   error_sys();
if (ret === 0)
   error_noavail();


> According to the man file:
>

> (Although without the functions equivalent 
> to the FD_* macros', the extension as a whole is getting pretty far removed 
> from the standard sockets library as it is.)
> 
> J

Yes, the goal is to follow a more php like behavior. Those who follow
the C-API will have some slight adjusting to, but the beauty of the
high-level language is that we can automate and simplify the
functionality.

This also makes it easier for people who don't know C to pickup the
functionality. 

-Jason
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
-- 
Jason T. Greene
Internet Software Engineer

<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]>

Use PHP: http://www.php.net



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

Re: [PHP-DEV] Re: Socket Rework Complete

[Jason Greene]

Thanks for the bug report, it will be fixed.

-Jason

On Fri, 2002-03-08 at 09:39, J Smith wrote:
> 
> I think I see bug number 1...
> 
> The system call for select() you to perform an indefinite blocking call if 
> you pass NULL as tv, but PHP's socket_select() doesn't seem to have that 
> feature. (It did in previous versions, from sometime in 4.0.7dev and up. I 
> caught that bug originally, actually.)
> 
> The old fix is still a valid one -- if the user doesn't pass arguments sec 
> and usec, pass NULL as the tv argument to the system select() call. I've 
> implemented it in last night's snapshot and it seems to work fine. 
> (Although I'm having a bitch re-writing our sockets stuff -- I have no idea 
> how to use the arrays yet versus the file descriptors, but I'll report as I 
> go.)
> 
> J
> 
> 
> Jason Greene wrote:
> 
> > For all those who don't follow CVS. The sockets extension modifications
> > I listed out a few weeks ago are complete, and will be included in the
> > 4.2.0 release.
> > 
> > The extension will still be marked as experimental; however, if 4.2.0
> > goes well, and there are few bugs, perhaps it can be marked as stable by
> > 4.3.0.
> > 
> > I ask all those that use the sockets extension try and get any bug
> > reports to me before RC1 closes (That way the fixes will make 4.2.0).
> > Also, between 4.2.0 and 4.3.0 would be a good time frame to suggest
> > behavior changes because once the extension is marked stable, these will
> > be a lot tougher to put through.
> > 
> > 
> > Thanks,
> > 
> > -Jason
> > 
> > 
> > 
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
-- 
Jason T. Greene
Internet Software Engineer

<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]>

Use PHP: http://www.php.net



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

Re: [PHP-DEV] Socket Rework Complete

[Jason Greene]

On Fri, 2002-03-08 at 03:48, Chris Vandomelen wrote:
> > For all those who don't follow CVS. The sockets extension modifications
> > I listed out a few weeks ago are complete, and will be included in the
> > 4.2.0 release.
> 
> I haven't been following CVS, nor have I really paid a lot of attention to
> the module. I have received the occasional email about the extension
> though, the most recent one being in relation to socket_select().

I understand. Due to the amount of work I have been doing on this
module, and the amount of usefulness I get out of this module, I am
planning on continuing the maintenance & enhancement work.
 
> In the current CVS, there is a bug in the socket_select() function that
> causes it to only return success or failure (RETURN_LONG(retval)), which,
> if I'm not mistaken about the rest of the API changes, should be changed
> to reflect a true/false value. 

Yes this is a bug, socket_select() should return false and print an
error message. It appears that socket_send() and socket_sendto() suffer
from the same bug. Thanks for catching this. A patch to resolve this
should be merged. (I should have time later today to correct that)


> It also doesn't give you access to the
> error which occured (since retval only represents the return of socket(),
> but nothing about the actual reason for failure), which is more the bug
> than anything.
> 
> The way I would go about fixing it would be to change socket_select() to
> return true or false, and if there was an error (as indicated by retval),
> store errno somewhere and let socket_last_error()/socket_clear_error()
> retrieve that value if there isn't a socket specified.

I agree with this approach, however, IMO this is a functionality
enhancement (soring a global last error), and probably should wait till
4.3.0.

Thoughts anyone?

> I've attached a unified diff of the changes to make. The changes are
> untested (I need to actually check out a complete version before making
> the changes...), but they should compile and work cleanly. (No
> guarantees.)


Just from an initial view:

A problem I notice in this patch is the constant use of
SOCKETSLS_FETCH(), a more efficient approach would be to modify the
macros in php_sockets.h to retrieve the global structure from TSRMLS().

Also there is a bug in the patch pertaining to the modifications to the
socket_last_error() function: arg1 should be initialized to NULL

> Chris
> 
> 
> 

Thanks for your feedback and patch,

-Jason



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

[PHP-DEV] Socket Rework Complete

[Jason Greene]

For all those who don't follow CVS. The sockets extension modifications
I listed out a few weeks ago are complete, and will be included in the
4.2.0 release. 

The extension will still be marked as experimental; however, if 4.2.0
goes well, and there are few bugs, perhaps it can be marked as stable by
4.3.0.

I ask all those that use the sockets extension try and get any bug
reports to me before RC1 closes (That way the fixes will make 4.2.0).
Also, between 4.2.0 and 4.3.0 would be a good time frame to suggest
behavior changes because once the extension is marked stable, these will
be a lot tougher to put through.


Thanks,

-Jason



-- 
Jason T. Greene
Internet Software Engineer

<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]>

Use PHP: http://www.php.net



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

[PHP-DEV] CVS Account Request: jasonlotito

[Jason Lotito]

PEAR Development.  I have already signed up and been approved for a PEAR Web Account, 
and setup a package for Color.  I wish to add and maintain my current Color Class, as 
well be allowed to add and manage other classes that I may add to PEAR.  I only need 
access to the PEAR section of CVS.  I would also like to contribute to the PEAR 
Documentation, primarily for my classes, but if I decide to document other classes, 
for those as well.

Other information about me, I am a PHP Developer for Clockmedia Inc. in Montreal, and 
also the webmaster of NewbieNetwork.net

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

Re: [PHP-DEV] Ping

[Jason Greene]

64 bytes from PHPDev Mailing List ([EMAIL PROTECTED]): icmp_seq=0
ttl=254 time=557 min
64 bytes from PHPDev Mailing List ([EMAIL PROTECTED]): icmp_seq=1
ttl=254 time=357 min
64 bytes from PHPDev Mailing List ([EMAIL PROTECTED]): icmp_seq=2
ttl=254 time=257 min
64 bytes from PHPDev Mailing List ([EMAIL PROTECTED]): icmp_seq=3
ttl=254 time=157 min


On Fri, 2002-03-01 at 14:46, Rasmus Lerdorf wrote:
> Testing the list
> 
> 
> -- 
> 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] build errors

[Jason Greene]

Are your Autoconf, and Automake in 2 different directory structures, but
symlinked? (cause that causes problems like this)

-Jason


On Fri, 2002-03-01 at 09:51, James Cox wrote:
> Ok, give it to me like i'm a 5 year old.. seems like i have some conflicts
> somewhere, but i don't know where else to look:
> 
> james@hub[~/php4]$ ./buildconf
> buildconf: checking installation...
> buildconf: autoconf version 2.13 (ok)
> buildconf: automake version 1.5 (ok)
> buildconf: libtool version 1.4 (ok)
> aclocal: configure.in: 1054: macro `AM_PROG_LIBTOOL' not found in library
> rebuilding Makefile templates
> rebuilding Makefile templates
> rebuilding configure
> configure.in:139: AC_PROG_CPP was called before AC_PROG_CC
> configure.in:836: /usr/bin/m4: Undefined macro `AC_PROG_LIBTOOL'
> autoconf: Undefined macros:
> ***BUG in Autoconf--please report*** AC_ADD_INCLUDE
> ***BUG in Autoconf--please report*** AC_TRY_DLOPEN_SELF
> configure.in:153:AC_MSG_RESULT([$php_cv_cc_dashr])
> configure.in:163:   AC_MSG_RESULT([$php_cv_cc_rpath])
> configure.in:183:AC_MSG_RESULT(${1}.${2} (ok))
> configure.in:242:AC_MSG_RESULT([$PHP_SAPI])
> configure.in:284: AC_DEFINE(HAVE_LIBSOCKET,1,[ ]) ], [
> configure.in:302: AC_DEFINE(HAVE_LIBNSL,1,[ ]) ],[
> configure.in:305:  AC_DEFINE(HAVE_LIBNSL,1,[ ]) ], [])
> configure.in:331: AC_DEFINE(HAVE_LIBSOCKET,1,[ ]) ], [
> configure.in:334:  AC_DEFINE(HAVE_LIBRESOLV,1,[ ])
> configure.in:434:  AC_DEFINE(HAVE_SOCKADDR_STORAGE,1,[Whether you have
> struct sockaddr_storage])
> configure.in:444:  AC_DEFINE(HAVE_IPV6,1,[Whether you have IPv6 support])
> configure.in:523:  AC_DEFINE(HAVE_GETADDRINFO,1,[Define if you have the
> getaddrinfo function])
> configure.in:529:PHP_AC_BROKEN_SPRINTF
> configure.in:549:dnl AC_MSG_RESULT([$ac_cv_type_in_addr_t])
> configure.in:551:  AC_DEFINE(in_addr_t, u_int, [ ])
> configure.in:633:  AC_DEFINE(PHP_SAFE_MODE,1,[ ])
> configure.in:635:  AC_DEFINE(PHP_SAFE_MODE,0,[ ])
> configure.in:645:
> AC_DEFINE(PHP_SAFE_MODE_EXEC_DIR,"/usr/local/php/bin", [ ])
> configure.in:646:   AC_MSG_RESULT([/usr/local/php/bin])
> configure.in:648:
> AC_DEFINE_UNQUOTED(PHP_SAFE_MODE_EXEC_DIR,"$withval", [ ])
> configure.in:649:   AC_MSG_RESULT([$withval])
> configure.in:652:
> AC_DEFINE(PHP_SAFE_MODE_EXEC_DIR,"/usr/local/php/bin", [ ])
> configure.in:653:   AC_MSG_RESULT([/usr/local/php/bin])
> configure.in:656:
> AC_DEFINE(PHP_SAFE_MODE_EXEC_DIR,"/usr/local/php/bin", [ ])
> configure.in:657:   AC_MSG_RESULT([/usr/local/php/bin])
> configure.in:66:  AC_MSG_ERROR([--with-shared-apache is not supported.
> Please refer to the documentation for using APXS])
> configure.in:674:  AC_DEFINE(PHP_SIGCHILD, 1, [ ])
> configure.in:676:  AC_DEFINE(PHP_SIGCHILD, 0, [ ])
> configure.in:683:  AC_DEFINE(MAGIC_QUOTES, 1, [ ])
> configure.in:685:  AC_DEFINE(MAGIC_QUOTES, 0, [ ])
> configure.in:698:AC_MSG_ERROR([Cannot locate libgcc. Make sure that gcc
> is in your path])
> configure.in:708:  AC_DEFINE(DEFAULT_SHORT_OPEN_TAG,"1",[ ])
> configure.in:70:  AC_MSG_ERROR([--with-apache and --with-apxs cannot be used
> together])
> configure.in:710:  AC_DEFINE(DEFAULT_SHORT_OPEN_TAG,"0",[ ])
> configure.in:721:AC_DEFINE(HAVE_DMALLOC,1,[Whether you have dmalloc])
> configure.in:724:AC_MSG_ERROR([Problem with enabling dmalloc. Please
> check config.log for details.])
> configure.in:734:  AC_DEFINE(HAVE_PHP_STREAM, 1, [Whether to use php
> streams])
> configure.in:740:  AC_DEFINE(HAVE_CRYPT,1,[ ])
> configure.in:789:AC_MSG_RESULT([$PHP_VERSIONING])
> configure.in:844:  AC_DEFINE(ZTS,1,[ ])
> configure.in:957:AC_DEFINE_UNQUOTED(PHP_BUILD_DATE,"$PHP_BUILD_DATE",[PHP
> build date])
> configure.in:959:AC_DEFINE_UNQUOTED(PHP_UNAME,"$PHP_UNAME",[uname -a
> output])
> configure.in:961:AC_DEFINE_UNQUOTED(PHP_OS,"$PHP_OS",[uname output])
> rebuilding acconfig.h
> rebuilding main/php_config.h.in
> /usr/bin/m4: autoheader.m4: No such file or directory
> NONE:0: /usr/bin/m4: ERROR: EOF in string
> 
> --
> James Cox :: [EMAIL PROTECTED] :: Landonize It! http://landonize.it/
> Was I helpful?  http://www.amazon.co.uk/exec/obidos/wishlist/23IVGHQ61RJGO/
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
-- 
Jason T. Greene
Internet Software Engineer

<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]>

Use PHP: http://www.php.net



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

[PHP-DEV] Parsing File Names

[Jason Dubya]

I am trying to create a script that will crawl through a directory, take
each file name, and parse it to get information from the filename.  This
is going to be used to place artists and song names into a database. 

The filenames are all in the following format: artist - songname.mp3

Is there an easy way to parse that to create two variables: $artist &
$songname?

 -- Jason Dubya



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

Re: [PHP-DEV] [PATCH] Better fix for PHP Safe Mode FilesystemCircumvention Problem

[Jason Greene]

Yes this for sure works. CLIENT_CAPABILITIES is a bitmask consisting of
the capabilities of the mysql client. CLIENT_LOCAL_FILES is bit 8 of the
mask (128). This information is sent to the server, which is actually
who decides whether local file uploads happen.

server code in mysql_server 3.23.49: sql_parse.cc:

if (!(thd->client_capabilities & CLIENT_LOCAL_FILES) ||
  ! opt_local_infile)
  { 
 send_error(&thd->net,ER_NOT_ALLOWED_COMMAND);
 goto error;
...

In earlier versions of mysql server this code is not present, however,
the file will still not be uploaded because of the code in the
mysql_load() function in sql_load.cc (which is present in every version
I have):



if (read_file_from_client && (thd->client_capabilities &
CLIENT_LOCAL_FILES))
  {
char tmp [FN_REFLEN+1],*end;
DBUG_PRINT("info",("reading local file"));
tmp[0] = (char) 251;/* NULL_LENGTH
*/
end=strnmov(tmp+1,ex->file_name,sizeof(tmp)-2);
(void) my_net_write(&thd->net,tmp,(uint) (end-tmp));
(void) net_flush(&thd->net);
    file = -1;
  }

I have tested this with great success.

Thanks
-Jason




On Thu, 2002-02-28 at 06:03, Zak Greant wrote:
> Hi Jason,
> 
> Did this actually work? I wrote almost the same code on my own and
> tested it, only to find that nothing changed. I walked through the code,
> but did not spot a point where the CLIENT_LOCAL_FILES is actually used
> other than:
> 
> % grep -rn CLIENT_LOCAL_FILES *
> ext/mysql/libmysql/libmysql.c:53:#define CLIENT_CAPABILITIES ...
> ext/mysql/libmysql/mysql_com.h:73:#define CLIENT_LOCAL_FILES128  ...
> 
> I have not yet looked further than this.
> 
> Monty cooked up a patch just before he went on vacation, but the patch
> is for a *way* newer version of libmysql and is not even remotely
> compatible.
> 
> We (errr.. the PHP we that is) may wish to consider updating the
> embedded libmysql.
> 
> --zak
> 
> On Wed, 2002-02-27 at 09:59, Jason Greene wrote:
> > This simple patch resolves this issue in a clean way, without
> > introducing complex sql pre-processing code that introduces mutex
> > problems.
> > 
> > The only issue is that it requires a modification to libmysql.c, which
> > provided that everyone here agrees with this fix, then I will post it to
> > [EMAIL PROTECTED] to get there reaction.
> > 
> > -Jason
> > 
> > 
> 
> > Index: ext/mysql/config.m4
> > ===
> > RCS file: /repository/php4/ext/mysql/config.m4,v
> > retrieving revision 1.38
> > diff -u -r1.38 config.m4
> > --- ext/mysql/config.m4 30 Nov 2001 18:59:45 -  1.38
> > +++ ext/mysql/config.m4 27 Feb 2002 16:51:33 -
> > @@ -41,6 +41,9 @@
> >  
> >  if test "$PHP_MYSQL" != "no"; then
> >AC_DEFINE(HAVE_MYSQL, 1, [Whether you have MySQL])
> > +  if test "$PHP_SAFE_MODE" = "yes"; then
> > + AC_DEFINE(DISALLOW_MYSQL_LOAD_LOCAL, 1, [Whether to disable load local])
> > +  fi
> >PHP_EXTENSION(mysql,$ext_shared)
> >  fi
> >  
> > Index: ext/mysql/libmysql/libmysql.c
> > ===
> > RCS file: /repository/php4/ext/mysql/libmysql/libmysql.c,v
> > retrieving revision 1.9
> > diff -u -r1.9 libmysql.c
> > --- ext/mysql/libmysql/libmysql.c   6 Nov 2001 16:59:07 -   1.9
> > +++ ext/mysql/libmysql/libmysql.c   27 Feb 2002 16:51:33 -
> > @@ -50,7 +50,11 @@
> >  uint   mysql_port=0;
> >  my_string  mysql_unix_port=0;
> >  
> > +#ifndef DISALLOW_MYSQL_LOAD_LOCAL
> >  #define CLIENT_CAPABILITIES(CLIENT_LONG_PASSWORD | CLIENT_LONG_FLAG | 
>CLIENT_LOCAL_FILES | CLIENT_TRANSACTIONS)
> > +#else 
> > +#define CLIENT_CAPABILITIES(CLIENT_LONG_PASSWORD | CLIENT_LONG_FLAG | 
>CLIENT_TRANSACTIONS) 
> > +#endif 
> >  
> >  #ifdef __WIN__
> >  #define CONNECT_TIMEOUT 20
> > 
> > 
> > 
> 
> > -- 
> > PHP Development Mailing List <http://www.php.net/>
> > To unsubscribe, visit: http://www.php.net/unsub.php
> -- 
>__  ___ ___   __
>   /  |/  /_ __/ __/ __ \/ /Zak Greant <[EMAIL PROTECTED]>   
>  / /|_/ / // /\ \/ /_/ / /__   MySQL AB,  Advocate
> /_/  /_/\_, /___/\___\_\___/   Calgary, Canada 
><___/   www.mysql.com   403.244.7213
> 
-- 
Jason T. Greene
Internet Software Engineer

<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]>

Use PHP: http://www.php.net



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

Re: [PHP-DEV] PHP 4.2.0 release process

[Jason Greene]

Sounds good to me.

-Jason


On Wed, 2002-02-27 at 12:31, Derick Rethans wrote:
> Hello folks,
> 
> after some overenthausiastic actions of me today I'd like to do it the
> formal way now. I think it's a good idea to start working on a PHP 4.2.0
> release now. Some interesting additions were added, the file upload code
> was rewriten and probably a lot more. I propose to branch to PHP_4_2_0 at
> next Wednesday March 6th. This should give most of you enough time to get
> your new code in. After that the QA team should gather the critical bugs
> and evaluate if they should be fixed before the 4.2.0 release. After this
> is evaluated it's time for the first RC, after which we can work at
> getting all those nasty little bugs out before we release.
> 
> In a few minutes I'll write another mail to QA with things that should be
> tested a lot, I believe Zak has some notes about that too.
> 
> regards,
> Derick
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
-- 
Jason T. Greene
Internet Software Engineer

<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]>

Use PHP: http://www.php.net



-- 
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 / configure.in /mainphp_version.h

[Jason Greene]

OK,
That sounds great, I will hurry with my patches then : )

-Jason

On Wed, 2002-02-27 at 12:18, [EMAIL PROTECTED] wrote:
> Hello,
> 
> On 27 Feb 2002, Jason Greene wrote:
> 
> > That should be enough time; however, if it is a problem, I could apply
> > to HEAD, then merge to 4.2 since the extension is labeled experimental.
> 
> I'd favor waiting a few days with the branching  so that you have time to
> commit your stuff. I don't think it's a good idea to merge new stuff to
> the release branches, whether the extension is experimental or not. My
> reason for this is that if this is done a lot, we would never be sure if a
> RC can be a final RC.
> 
> > I was hoping to finish my work and then remove experimental status from
> > the extension, but perhaps that should wait till 4.3, that way any final
> > tweaks can be made in 4.3.0-Dev.
> >
> > What do you think?
> 
> As the extension isn't quite finished I think the EXPERIMENTAL status
> should be gone with PHP 4.3.0, and not yet with PHP 4.2.0.
> 
> Derick
> 
-- 
Jason T. Greene
Internet Software Engineer

<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]>

Use PHP: http://www.php.net



-- 
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 / configure.in /mainphp_version.h

[Jason Greene]

Clarification

I was referring to the status change in 4.3 and the features in by 4.2
  

On Wed, 2002-02-27 at 12:11, Jason Greene wrote:
> That should be enough time; however, if it is a problem, I could apply
> to HEAD, then merge to 4.2 since the extension is labeled experimental.
> 
> I was hoping to finish my work and then remove experimental status from
> the extension, but perhaps that should wait till 4.3, that way any final
> tweaks can be made in 4.3.0-Dev.
> 
> What do you think?
> 
> -Jason
> 
> 
> 
> On Wed, 2002-02-27 at 12:05, Andi Gutmans wrote:
> > I don't see any reason not to postpone the branching by a couple of days if 
> > that's enough time for you.
> > 
> > Andi
> > 
> > At 11:57 AM 2/27/2002 -0600, Jason Greene wrote:
> > >I was hoping the sockets work I was planning on would make the 4.2
> > >branch. I guess thats not possible?
> > >
> > >-Jason
> > >
> > >
> > >
> > >On Wed, 2002-02-27 at 11:19, Rasmus Lerdorf wrote:
> > > > > Rasmus Lerdorf wrote:
> > > > > > By the way, when was this 4.2.0 branch created?  I saw no
> > > > > > php-dev/php-qa discussion on this.
> > > > >
> > > > >   Derick is writing the mail in question right now. We're currently
> > > > >   discussing the process on #php.bugs @ EFnet.
> > > >
> > > > Well, you have the process upside down.  You need to send the email to
> > > > php-dev first so people who have outstanding stuff have a chance to get it
> > > > in.  Give them at least 24 hours to do so and then you can branch.
> > > >
> > > > -Rasmus
> > > >
> > > >
> > > > --
> > > > PHP Development Mailing List <http://www.php.net/>
> > > > To unsubscribe, visit: http://www.php.net/unsub.php
> > > >
> > >--
> > >Jason T. Greene
> > >Internet Software Engineer
> > >
> > ><[EMAIL PROTECTED]>
> > ><[EMAIL PROTECTED]>
> > ><[EMAIL PROTECTED]>
> > >
> > >Use PHP: http://www.php.net
> > >
> > >
> > >
> > >--
> > >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
> > 
> -- 
> Jason T. Greene
> Internet Software Engineer
> 
> <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]> 
> <[EMAIL PROTECTED]>
> 
> Use PHP: http://www.php.net
> 
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
-- 
Jason T. Greene
Internet Software Engineer

<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]>

Use PHP: http://www.php.net



-- 
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 / configure.in /mainphp_version.h

[Jason Greene]

That should be enough time; however, if it is a problem, I could apply
to HEAD, then merge to 4.2 since the extension is labeled experimental.

I was hoping to finish my work and then remove experimental status from
the extension, but perhaps that should wait till 4.3, that way any final
tweaks can be made in 4.3.0-Dev.

What do you think?

-Jason



On Wed, 2002-02-27 at 12:05, Andi Gutmans wrote:
> I don't see any reason not to postpone the branching by a couple of days if 
> that's enough time for you.
> 
> Andi
> 
> At 11:57 AM 2/27/2002 -0600, Jason Greene wrote:
> >I was hoping the sockets work I was planning on would make the 4.2
> >branch. I guess thats not possible?
> >
> >-Jason
> >
> >
> >
> >On Wed, 2002-02-27 at 11:19, Rasmus Lerdorf wrote:
> > > > Rasmus Lerdorf wrote:
> > > > > By the way, when was this 4.2.0 branch created?  I saw no
> > > > > php-dev/php-qa discussion on this.
> > > >
> > > >   Derick is writing the mail in question right now. We're currently
> > > >   discussing the process on #php.bugs @ EFnet.
> > >
> > > Well, you have the process upside down.  You need to send the email to
> > > php-dev first so people who have outstanding stuff have a chance to get it
> > > in.  Give them at least 24 hours to do so and then you can branch.
> > >
> > > -Rasmus
> > >
> > >
> > > --
> > > PHP Development Mailing List <http://www.php.net/>
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> >--
> >Jason T. Greene
> >Internet Software Engineer
> >
> ><[EMAIL PROTECTED]>
> ><[EMAIL PROTECTED]>
> ><[EMAIL PROTECTED]>
> >
> >Use PHP: http://www.php.net
> >
> >
> >
> >--
> >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
> 
-- 
Jason T. Greene
Internet Software Engineer

<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]>

Use PHP: http://www.php.net



-- 
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 / configure.in /mainphp_version.h

[Jason Greene]

I was hoping the sockets work I was planning on would make the 4.2
branch. I guess thats not possible? 

-Jason



On Wed, 2002-02-27 at 11:19, Rasmus Lerdorf wrote:
> > Rasmus Lerdorf wrote:
> > > By the way, when was this 4.2.0 branch created?  I saw no
> > > php-dev/php-qa discussion on this.
> >
> >   Derick is writing the mail in question right now. We're currently
> >   discussing the process on #php.bugs @ EFnet.
> 
> Well, you have the process upside down.  You need to send the email to
> php-dev first so people who have outstanding stuff have a chance to get it
> in.  Give them at least 24 hours to do so and then you can branch.
> 
> -Rasmus
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
-- 
Jason T. Greene
Internet Software Engineer

<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]>

Use PHP: http://www.php.net



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

[PHP-DEV] [PATCH] Better fix for PHP Safe Mode Filesystem CircumventionProblem

[Jason Greene]

This simple patch resolves this issue in a clean way, without
introducing complex sql pre-processing code that introduces mutex
problems.

The only issue is that it requires a modification to libmysql.c, which
provided that everyone here agrees with this fix, then I will post it to
[EMAIL PROTECTED] to get there reaction.

-Jason


Index: ext/mysql/config.m4
===
RCS file: /repository/php4/ext/mysql/config.m4,v
retrieving revision 1.38
diff -u -r1.38 config.m4
--- ext/mysql/config.m4 30 Nov 2001 18:59:45 -  1.38
+++ ext/mysql/config.m4 27 Feb 2002 16:51:33 -
@@ -41,6 +41,9 @@
 
 if test "$PHP_MYSQL" != "no"; then
   AC_DEFINE(HAVE_MYSQL, 1, [Whether you have MySQL])
+  if test "$PHP_SAFE_MODE" = "yes"; then
+ AC_DEFINE(DISALLOW_MYSQL_LOAD_LOCAL, 1, [Whether to disable load local])
+  fi
   PHP_EXTENSION(mysql,$ext_shared)
 fi
 
Index: ext/mysql/libmysql/libmysql.c
===
RCS file: /repository/php4/ext/mysql/libmysql/libmysql.c,v
retrieving revision 1.9
diff -u -r1.9 libmysql.c
--- ext/mysql/libmysql/libmysql.c   6 Nov 2001 16:59:07 -   1.9
+++ ext/mysql/libmysql/libmysql.c   27 Feb 2002 16:51:33 -
@@ -50,7 +50,11 @@
 uint   mysql_port=0;
 my_string  mysql_unix_port=0;
 
+#ifndef DISALLOW_MYSQL_LOAD_LOCAL
 #define CLIENT_CAPABILITIES(CLIENT_LONG_PASSWORD | CLIENT_LONG_FLAG | 
CLIENT_LOCAL_FILES | CLIENT_TRANSACTIONS)
+#else 
+#define CLIENT_CAPABILITIES(CLIENT_LONG_PASSWORD | CLIENT_LONG_FLAG | 
+CLIENT_TRANSACTIONS) 
+#endif 
 
 #ifdef __WIN__
 #define CONNECT_TIMEOUT 20



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

Re: [PHP-DEV] Re: Sockets Extension Rework (API, etc...) VERY LONG

[Jason Greene]

On Thu, 2002-02-21 at 18:09, J Smith wrote:
> 
> I'm all for fixing this extension up to make it better,

Great!!!

>  but I'm a little 
> concerned with totally dropping the fd_* functions. How would you mimic 
> their use in something like a multiplexing using a blocking call situation 
> after the change? I have no idea how it can be done without using the fd_* 
> function. (But then again, I'm used to using the FD_* macros in C, so maybe 
> there's better way in PHP.)


Well, since you know the C-API, lets look at if from the C socket API 
perspective. select() is designed to take 3 arrays. The problem with
arrays is that they take up memory and processing time. In application
space this really isn't a problem, but in the kernel, every saved byte
counts. To optimize this they emulated arrays using bit masks. Another
optimization they performed is to have you pass the highest file
descriptor + 1 into select. (that way they only process part of the bit
mask.)


What I am getting at, is that FD_* was an interface designed strictly
for kernel performance. Direct manipulation of these low level values
does not really belong in a high-level language.

The method that makes the most sense is to use php arrays in place of
the fd masks. Everything would work exactly the same, except it would be
much easier to interface, it would be less buggy, and require less code.

By the way, the bug with the socket_fd_functions, is that it may set
your maximum file descriptor incorrectly, and this would cause you to
miss events occurring on ready sockets. (This occurs anytime you call
socket_fd_clear() on a socket, or if you don't add sockets in order they
were opened ex. 3, 1, 2 will cause you to lose file descriptor 3.


example




 
> Just wondering, because I acutally use this extension in a multiplexing 
> kind of way with indefinite socket_select blocking and multiple clients and 
> all that jazz already. Yeah, I know it's experimental and stuff, but it has 
> yet to fail, even with my "daemon" script running for weeks on end under a 
> fair load. I use the socket functions in a search engine that's constantly 
> listening for connections using socket_select, and the socket_fd* functions 
> are used quite a bit, hence my concern. (Not that I'm adverse to the 
> change, 'cause I'm sure I'll cope, but I'd like to know if it will be 
> possible to port my existing stuff over to the new API.)

I would like to see this extension become stable so that people can
start relying on somewhat frozen behavior.

To answer your question It should be pretty easy to port your code to
the newer API.
 

I appreciate hearing concerns like this, and I hope you and others
continue to speak up. : ) 

-Jason

> 
> J
> 
> 
> Jason Greene wrote:
> 
> > 
> > 2. Get rid of socket_fd_*.
> > -
> > 
> > It makes little sense to make fd masks available to the user, because
> > this can be much easier to handle by using arrays.
> > 
> > This will fix the max_fd code that attempts to calculate the highest
> > file descriptor in the fd_set.
> > 
> > Select would then look like
> > socket_select (array read_socks(), array write_socks(), array
> > except_socks(), int tv_sec, int uv_sec)
> > 
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
-- 
Jason T. Greene
Internet Software Engineer

<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]>

Use PHP: http://www.php.net



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

Re: [PHP-DEV] Sockets Extension Rework (API, etc...) VERY LONG

[Jason Greene]

On Thu, 2002-02-21 at 01:40, Derick Rethans wrote:
> Hey Jason,
> 
> On 20 Feb 2002, Jason Greene wrote:
> 
> > Instead of just committing a gigantic patch to solve these problems, and
> > redefine the extensions behavior, I decided to open a thread for
> > discussion on how I intend to solve all the problems.
> >
> > My solution does involve modifying pieces of the API, which causes BC
> > concerns. I do think about these things, and I really think we should
> > stabilize and finalize this module, as we have already radically changed
> > the API once before.
> 
> Just fix it so that it is both consistent and that the extension has a
> clean API. I wouldn't worry about BC here, cause the extension is
> experimental (with a big message in the manual).

Thats what I was hoping : )

> 
> > Timeline & Stabilization
> > =
> >
> > I would like to fix all of this by 4.2.X. I propose that we then mark
> > the extension as stable, and freeze the API.
> >
> >
> > Please send your feedback on your thoughts and concerns on these
> > changes.
> 
> Sounds all sane to me. Good luck!

Great!!, Well provided I don't get any negative feedback on these, I
will start right away!!!

-Jason


> Derick
> 
> -
> PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
>  SRM: Site Resource Manager - www.vl-srm.net
> -
> 
> 
> -- 
> 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