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]

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. note: I have just real run-tests.php and see a that it submits
 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.)
 
 Note: I only just realised that if I run `make test` and it print no
 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]
 
 **no comment from me
 
 crc32() function [ext/standard/tests/strings/crc32.phpt]
 
 **crc32: uses Zend's RETVAL_LONG but test expects 32-bit overflow.
 
 strtotime() function [ext/standard/tests/time/002.phpt]
 
 **no comment from me
 
 Methods via variable name, bug #20120 [tests/classes/bug20120.phpt]
 
 **My bison is bison-1.50, addressed by the bug fix (closed). This
problem was also visible as an error message during PEAR
installation.
 
 =
 
 Given the bison problem, my previous comments about Zend might be
 doubtful. working Mmm, new bison fixed the last failed test. Other
 tests unchanged wrt 4.3.0pre2. Latest CVS version 

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. note: I have just real run-tests.php and see a that it submits
  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.)
  
  Note: I only just realised that if I run `make test` and it print no
  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]
  
  **no comment from me
  
  crc32() function [ext/standard/tests/strings/crc32.phpt]
  
  **crc32: uses Zend's RETVAL_LONG but test expects 32-bit overflow.
  
  strtotime() function [ext/standard/tests/time/002.phpt]
  
  **no comment from me
  
  Methods via

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

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

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] 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 a href
 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

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] 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, param 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]

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, param 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] 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]

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

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

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

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

[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

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] 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;
 }
 }
   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.c8 May 2002 18:43:19 -   1.341
   +++ zend_execute.c25 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

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:
 
  ?php
  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] 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: [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

[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

---BeginMessage---

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

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

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



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

[PHP-DEV] Re: Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Right/Left Shift Zero Fill operator

[Jason T . Greene]

 
 From: Jeroen van Wolffelaar [EMAIL PROTECTED]
 Date: 2001/09/10 Mon PM 01:58:03 CDT
 To: Vlad Krupin [EMAIL PROTECTED],
   Alexander Wirtz [EMAIL PROTECTED]
 CC: Jason Greene [EMAIL PROTECTED],
   [EMAIL PROTECTED],
   [EMAIL PROTECTED],
   Andrei Zmievski [EMAIL PROTECTED],
   Andi Gutmans [EMAIL PROTECTED]
 Subject: Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Right/Left Shift Zero 
Fill operator
 
  FWIW:
  Signed shift seems to make little sense to me personally, since we are
  just dealing with a row of bits, and if you really want to do a quick
  multiplication/division, you might just as well use a * or / operator -
  it is not going to hurt that much:).
 
 I completely agree

Which is faster, adding a number several hundred times
or shifting a few bits?
(no need to answer just making a point)

 
  *However*, it's been possible in
  different languages since before I had my first computer (e.g. SHL/SHR
  and SAL/SAR in asm x86), so we might provide the same functionality and
  create a new operator to discriminate between signed and unsigned
  shifts.Just a thought. Don't kill me if that would be polluting the
  language.
 
 IMHO: If other languages have strange things, I don't see why PHP should
 take it over... Don't copy bad operators!
 But... currently, how does PHP handle this? I'm afraid the wrong way?
 
 --Jeroen
Yep the signed way.

PHP just calls C's , which shifts according to 
the datatype. If the datatype is signed (which in php it is)
it performs a signed shift, if it is unsigned it performs an unsigned shift. The 
problem lies in the fact that a loosely typed language has no concept of sign/unsigned 
types. Java got around this by creating a new operator for unsigned shifting . 

I personally have never had a need to shift signed values, but someone has spoken up 
that does, and as such I believe we should leave compatibility with this. 

It looks like we have no choice but to follow java on this one. Does anyone disagree?

-Jason





 
 


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: Re: sysvsem extention question

[Jason T . Greene]

  Last, i don't see why the implementation as exists, requires 3
  semaphores.

I just looked over the code, and the reason for this is it specifically designed for a 
multi-process web environment. The most common method for semaphore initialization is 
in the parent process right before fork.  There is no parent initializer for a php 
module author, and since each child has its own environment, there is no way to know 
when to initialize the semaphore. 

The way that Tom solved that problem was to create a USAGE semaphore which is used 
to insure that the semaphore is only initialized once. There must have been some sort 
of race condition because the purpose of the 3rd semaphore is a lock.

This is actually a sharp way to handle the problem of no central way to initialize.

-Jason



-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: Re: sysvsem extention question

[Jason T . Greene]

 As far as creating the new module goes, it shouldn't be 'to much effort'. The basic 
implimentation of system v semaphores
 is actualy quite simple, its the usage of sempahores that can be very confusing :-) 
sysv sem's are often refered to as the
 most difficult to comprehend of the sysv standards.

Well they took a simple concept and made it extremly complex.
 
 I would be more then willing to donate my time and efforts to that project, and i do 
have some knowledge of how semaphores
 can be used (reader-writer, resource count and lock implimentations). However as i 
mentioned before, my last C project is
 some years ago, also my knowledge of Zend internals is limited to the php-usage scope
 
 do note a locked semaphore == 0, any value above 0 allows for a 'lock', this is done 
to allow multiple client-locks
 clasical example is : if the printer manager daemon has 5 printers, it creates a 
semaphore with a max_acquire of 5. (so
 acquire count == 5). Every client connecting, lowers that count... untill its zero. 
Then the client blocks 'till the value
 is positive again.
 
 Proposed API of the sysvsem
 ---
 
 * $sem = sem_get($key,$max_acquire,$perms)
Gets or creates a semaphore id, id is returned in $sem
 * $ret = sem_acquire($sem)
Tries to lowerer the acquire count of the semaphore. If count is already 0, wait 
till it is raised (by sem_release) or
 returns an error (sem_remove was called or invalid permission to get semaphore). 
note: when the client blocks 'semzcnt' is
 increased (semzcnt = # of processes waiting for lock)
 * $ret = sem_release($sem)
 Increases the acquire count
 
 [proposed new function]
 * $count = sem_get_waiting($sem)
 Returns the amount of processes blocking on a semaphore acquire call. I propose 
-1 = error, 0  incicates # of waiting
 processes.

I like this, but I am wondering if we should perhaps support  some of the more 
advanced capibilities of sysv sems, like support of operation arrays with semop and 
IPC_PRIVATE, etc.

 
 Documentation
 --
 I'd be happy to help write up some documentation, general how-to-use semaphores for 
usage in php docs, plus some example
 implimentations..

That would be great!!


-Jason

 
 I will see how far i can get using the existing implimentation as a template for 
implimenting a php module.. however be
 sure i'll come knocking for help fairly soon :-)
 
 -- Chris
 
 Jason Greene wrote:
 
  There probably should be a full implementation of semaphores in php. If you
  have a need for this, we should discuss exactly how it should be implemented.
  I will have some free time available soon, so I can start working on this. Though 
I have
  a couple other projects as well. If you would be interested in contributing a CVS
  account can be arranged. This should probably start as a separate module, and then
  eventually replace the sysvsem extension as it is no long being actively 
maintained.
 
  I have a great desire for php to function well as a standalone scripting language
  as well as web, so I am always interested as projects like this.
 
  Is there anyone else who would find this useful?
 
  -Jason
 
  - Original Message -
  From: Tom May [EMAIL PROTECTED]
  To: Chris Chabot [EMAIL PROTECTED]
  Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
  Sent: Tuesday, August 21, 2001 1:58 PM
  Subject: Re: sysvsem extention question
 
   First off, before you get the wrong impression of my answer, let me
   say that your observation It all seems kinda kludgy and quick-hack
   for a specific  project, and not 'sysv semaphores implimented in
   php' is right on.
  
   Chris Chabot [EMAIL PROTECTED] writes:
  
I have been playing with the idea of making some application backend
services using pcntl (for singaling and fork)+ sysvsem's (for
synchronisation).
  
   Cool.  But see below.
  
However while reading thru the sysvsem source code, i noticed the
behaviour of the semaphores in PHP is basicly as a 'lock' (as one would
use a file lock w/ flock()). From what i understand from my advanced
unix programming book, and the linux man pages, this is not what
semaphores are supposed to be (though they can be abused to be so).
   
The way one would -expect- semaphores to function on a unix platform
is best described in Linux Programmers Guide at

http://uiarchive.uiuc.edu/mirrors/ftp/ftp.ibiblio.org/pub/Linux/docs/linux-doc-project/programmers-guide/lpg-0.4.pdf
(page 46 and on).
   
A short sumary would be: a semaphore is a resource counter (not an
absolute lock).
  
   A lock is just a degenerate case.  A slightly less degenerate case
   (that can't be implemented with flock) is when you want to allow N
   users of the resource instead of just one.
  
The main this is that a process other then the process that acquired
the semaphore can decrease the semaphore count, thus releasing it for