Bug #53727 [Com]: Inconsistent behavior of is_subclass_of with interfaces

2011-06-30 Thread ralph at smashlabs dot com 
Edit report at https://bugs.php.net/bug.php?id=53727edit=1

 ID: 53727
 Comment by: ralph at smashlabs dot com
 Reported by:mattknight at xymail dot co dot uk
 Summary:Inconsistent behavior of is_subclass_of with
 interfaces
 Status: Open
 Type:   Bug
 Package:Class/Object related
 Operating System:   Gentoo x86_64
 PHP Version:5.3.5
 Block user comment: N
 Private report: N

 New Comment:

Dmitry,

The patch called fix-is_subclass_of-PHP_5_3.diff does the following:

* Alters the existing Zend/tests/is_a.phpt to alter the bad
  expectation,

* Adds a new test file for is_subclass_of() as 
  Zend/tests/is_subclass_of.phpt

* Finally alters is_a_impl() in the following ways:

  * If an object was provided as the first parameter, and we are
inside of an is_subclass_of call (known by the flag
only_subclass), then assign the class entry of the object

  * Next, determine if the instance_ce provided is the same class
entry as that we are testing against (parameter 2 of the
is_subclass_of() call ... if it is, return false

  * Now that we know the instance_ce is not the same as the class
entry for the test class, allow is_a_impl to pass these class
entries to instanceof_function, and return that value

It is pretty straight forward, and any way I look at it, there are
few consequences to this patch.

Thanks,
Ralph


Previous Comments:

[2011-01-13 09:13:50] mattknight at xymail dot co dot uk

Yes, it would also be fine to return false when comparing against an ancestral 
interface, just so long as the behaviour is consistent.

Expected result:

false
true
false
true


[2011-01-12 18:06:36] chris at cmbuckley dot co dot uk

Apologies; I actually meant:

false
true
false
true


[2011-01-12 17:58:37] chris at cmbuckley dot co dot uk

One could argue that the expected result is actually:

true
true
false
false

since neither classes are technically subclasses of the interface. Either 
way, the actual behaviour is undesirable :-)


[2011-01-12 17:08:59] mattknight at xymail dot co dot uk

Description:

is_subclass_of() can take a string as the first parameter, as well as a second 
string parameter of the class name. It will check to see whether a class with 
the name specified in the first parameter is a subclass of the class with the 
name specified in the second parameter.

This logic, however, doesn't apply with interfaces.

The function behaves as expected for classes that don't directly implement an 
interface, but won't recognise the interface on a class that does directly 
implement it.

Test script:
---
?php

interface MyInterface {
const TEST_CONSTANT = true;
}

class ParentClass implements MyInterface { }

class ChildClass extends ParentClass { }

echo (is_subclass_of('ChildClass', 'MyInterface') ? 'true' : 'false') . \n;
echo (defined('ChildClass::TEST_CONSTANT') ? 'true' : 'false') . \n;

echo (is_subclass_of('ParentClass', 'MyInterface') ? 'true' : 'false') . \n;
echo (defined('ParentClass::TEST_CONSTANT') ? 'true' : 'false') . \n;

Expected result:

true
true
true
true

Actual result:
--
true
true
false
true






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=53727edit=1

#44462 [Com]: Can not compile embed sapi on OSX

2009-06-05 Thread ralph at smashlabs dot com 
 ID:   44462
 Comment by:   ralph at smashlabs dot com
 Reported By:  graham+php at nexopia dot com
 Status:   No Feedback
 Bug Type: Compile Failure
 Operating System: OSX
 PHP Version:  5.2CVS-2009-03-25
 New Comment:

I can confirm this is still an issue


  ld: duplicate symbol _spl_ce_SplDoublyLinkedList in
ext/spl/.libs/spl_dllist.o and ext/spl/.libs/php_spl.o
  collect2: ld returned 1 exit status
  make: *** [libphp5.la] Error 1 


I can compile statically though.  Can you reopen?


Previous Comments:


[2009-04-09 01:00:00] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.



[2009-04-01 11:25:00] j...@php.net

There is no working patch here. Or are you saying you can not compile 
PHP (without the experimental embed sapi)? FYI: it works fine for me.




[2009-03-25 18:28:07] graham+php at nexopia dot com

Incidentally, this bug is now a year old, has a functioning patch that
resolves the issue, and has still not been fixed upstream.



[2008-04-25 17:56:46] cthompson at nexopia dot com

I just sent the following to the php-install mailing list for
feedback.

Modify php-5.2.5/Zend/zend_ini_scanner.c:

--- /Users/cthompson/php-5.2.5.clean/Zend/zend_ini_scanner.c   
2007-11-08 09:36:37.0 -0600
+++ ./zend_ini_scanner.c2008-04-25 10:16:27.0 -0600
@@ -478,7 +478,7 @@
 #define yymore() yymore_used_but_not_detected
 #define YY_MORE_ADJ 0
 #define YY_RESTORE_YY_MORE_OFFSET
-char *yytext;
+//char *yytext;
 #define INITIAL 0
 /*

+--+


Modify php-5.2.5/Zend/zend_language_scanner.c:
--- /Users/cthompson/php-5.2.5.clean/Zend/zend_language_scanner.c
2007-11-08 09:36:37.0 -0600
+++ ./zend_language_scanner.c2008-04-25 10:17:15.0 -0600
@@ -3009,7 +3009,7 @@
 #define yymore() (yy_more_flag = 1)
 #define YY_MORE_ADJ yy_more_len
 #define YY_RESTORE_YY_MORE_OFFSET
-char *yytext;
+//char *yytext;
 #define INITIAL 0

 /*


This REMOVES the definition of yytext.  I think this is okay because
the various defines in those files actually end up using the yy_text in
zend_global.h, at least as far as I can see.

Certainly, this allows PHP to compile but I am not at all sure if this
is going to cause other problems.  Could someone please give me some
feedback?


Additionally, I believe php-5.2.5/sapi/cli/config.m4 should be modified
to compile using libtool on OS X:
--- /Users/cthompson/php-5.2.5.clean/sapi/cli/config.m42007-07-11
17:20:36.0 -0600
+++ ./config.m42008-04-25 11:51:57.0 -0600
@@ -17,7 +17,7 @@
 BUILD_CLI=echo '\#! .'  php.sym  echo php.sym  nm -BCpg
\`echo \$(PHP_GLOBAL_OBJS) \$(PHP_CLI_OBJS) | sed
's/\([A-Za-z0-9_]*\)\.lo/\1.o/g'\` | \$(AWK) '{ if (((\$\$2 == \T\) ||
(\$\$2 == \D\) || (\$\$2 == \B\))  (substr(\$\$3,1,1) != \.\)) {
print \$\$3 } }' | sort -u  php.sym  \$(LIBTOOL) --mode=link \$(CC)
-export-dynamic \$(CFLAGS_CLEAN) \$(EXTRA_CFLAGS)
\$(EXTRA_LDFLAGS_PROGRAM) \$(LDFLAGS) -Wl,-brtl -Wl,-bE:php.sym
\$(PHP_RPATHS) \$(PHP_GLOBAL_OBJS) \$(PHP_CLI_OBJS) \$(EXTRA_LIBS)
\$(ZEND_EXTRA_LIBS) -o \$(SAPI_CLI_PATH)
 ;;
   *darwin*)
-BUILD_CLI=\$(CC) \$(CFLAGS_CLEAN) \$(EXTRA_CFLAGS)
\$(EXTRA_LDFLAGS_PROGRAM) \$(LDFLAGS) \$(NATIVE_RPATHS)
\$(PHP_GLOBAL_OBJS:.lo=.o) \$(PHP_CLI_OBJS:.lo=.o) \$(PHP_FRAMEWORKS)
\$(EXTRA_LIBS) \$(ZEND_EXTRA_LIBS) -o \$(SAPI_CLI_PATH)
+BUILD_CLI=\$(LIBTOOL) --mode=link \$(CC) \$(CFLAGS_CLEAN)
\$(EXTRA_CFLAGS) \$(EXTRA_LDFLAGS_PROGRAM) \$(LDFLAGS) \$(NATIVE_RPATHS)
\$(PHP_GLOBAL_OBJS) \$(PHP_CLI_OBJS) \$(PHP_FRAMEWORKS) \$(EXTRA_LIBS)
\$(ZEND_EXTRA_LIBS) -o \$(SAPI_CLI_PATH)
 ;;
   *netware*)
 BUILD_CLI=\$(LIBTOOL) --mode=link \$(CC) -export-dynamic
\$(CFLAGS_CLEAN) \$(EXTRA_CFLAGS) \$(EXTRA_LDFLAGS_PROGRAM) \$(LDFLAGS)
\$(PHP_RPATHS) \$(PHP_CLI_OBJS) \$(EXTRA_LIBS) \$(ZEND_EXTRA_LIBS)
-Lnetware -lphp5lib -o \$(SAPI_CLI_PATH)


Of course, the shipping version of PHP 5.2.5 would then also need the
php-5.2.5/configure file changing, though presumably this is
autogenerated from the fragments:
--- /Users/cthompson/php-5.2.5.clean/configure2007-11-08
09:36:28.0 -0600
+++ ./configure2008-04-25 11:27:46.0 -0600
@@ -9180,7 +9180,7 @@
 BUILD_CLI=echo '\#! .'  php.sym  echo php.sym  nm -BCpg
\`echo \$(PHP_GLOBAL_OBJS) \$(PHP_CLI_OBJS) | sed
's/\([A-Za-z0-9_]*\)\.lo/\1.o/g'\` | \$(AWK) '{ if (((\$\$2 == \T\) ||
(\$\$2 == \D\) || (\$\$2 == \B\))  (substr(\$\$3,1,1) != \.\)) {
print

#48166 [NEW]: RecursiveIteratorIterator does not persist state parent in getChildren()

2009-05-06 Thread ralph at smashlabs dot com 
From: ralph at smashlabs dot com
Operating system: *nix, osx, win32
PHP version:  5.2.9
PHP Bug Type: SPL related
Bug description:  RecursiveIteratorIterator does not persist state parent in 
getChildren()

Description:

Currently, its difficult to extend RecursiveFilterIterator() with
additional __construct() arguments (for configuring its behavior).  The
reason its difficult is b/c when getChildren() is called, a new instance of
the RFI is created (only way you'd know this is if you look into the source
of RFI).

Workaround currently is this (But is not generic enough to all use
cases):

replace getChildren():

function getChildren()
{
if (empty($this-ref)) {
$this-ref = new ReflectionClass($this);
}
return
$this-ref-newInstance($this-getInnerIterator()-getChildren(),
$this-_otherArgs);
}

Reproduce code:
---
$rArray = array('a' = array('ab', 'ac', 'ad' = array('ada', 'adc')), 'b'
= array('bb', 'bc'));

$ri = new RecursiveArrayIterator($rArray);
$filter = new MyRFI($ri, 'argument');
$iterator = new RecursiveIteratorIterator($filter);

foreach ($iterator as $key = $item) {
echo $key . ' - ' . $item . PHP_EOL;
}

class MyRFI extends RecursiveFilterIterator
{
protected $_otherArg = null;

public function __construct($iterator, $otherArg = null)
{
$this-_otherArg = $otherArg;
parent::__construct($iterator);
}

public function accept()
{
echo ($this-_otherArg) ? 'Arg Present' : 'Arg NOT Present';
echo PHP_EOL;
return true;
}
}

Expected result:

Arg Present
Arg Present
0 - ab
Arg Present
1 - ac
Arg Present
Arg Present
0 - ada
Arg Present
1 - adc
Arg Present
Arg Present
0 - bb
Arg Present
1 - bc 

Actual result:
--
Arg Present
Arg NOT Present
0 - ab
Arg NOT Present
1 - ac
Arg NOT Present
Arg NOT Present
0 - ada
Arg NOT Present
1 - adc
Arg Present
Arg NOT Present
0 - bb
Arg NOT Present
1 - bc


-- 
Edit bug report at http://bugs.php.net/?id=48166edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48166r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48166r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48166r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48166r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=48166r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48166r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=48166r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=48166r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=48166r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=48166r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=48166r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=48166r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=48166r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48166r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=48166r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48166r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=48166r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=48166r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=48166r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=48166r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=48166r=mysqlcfg

#48052 [Bgs]: SPLStack::setIteratorMode() throw exception on keep/delete flag

2009-05-06 Thread ralph at smashlabs dot com 
 ID:   48052
 User updated by:  ralph at smashlabs dot com
 Reported By:  ralph at smashlabs dot com
 Status:   Bogus
 Bug Type: SPL related
 Operating System: *
 PHP Version:  5.3, 6CVS (2009-04-25)
 Assigned To:  colder
 New Comment:

Thats fine, and that works.

I guess this needs to be documented inside of setIteratorMode(), I
would have never guessed that flags are replaced, my initial assumption
would be that they are OR'd with the existing flags.

Thanks for clearing this up.
-ralph


Previous Comments:


[2009-05-02 13:29:36] col...@php.net

The reason is that setIteratorMode replaces the iterator flags
entirely, so you need to specify the order of iteration as well if you
want to change the KEEP/DELETE.


Since you use a stack, simply use:
SplDoublyLinkedList:: IT_MODE_DELETE |
SplDoublyLinkedList::IT_MODE_LIFO





[2009-04-22 16:50:24] ralph at smashlabs dot com

Description:

Attempting to change the IteratorMode throws an exception.

The is probably due to the code that changes the LIFO/FIFO ordering
that is also settable via the inherited method of
SplDoublyLinkedList::setIteratorMode().



Reproduce code:
---
?php

$s = new SPLStack(); 
$s-setIteratorMode(SplDoublyLinkedList::IT_MODE_DELETE);

Expected result:

Do not throw exception on the following use cases:

-setIteratorMode(SplDoublyLinkedList::IT_MODE_DELETE)
-setIteratorMode(SplDoublyLinkedList::IT_MODE_KEEP)

Actual result:
--
PHP Fatal error:  Uncaught exception 'RuntimeException' with message
'Iterators' LIFO/FIFO modes for SplStack/SplQueue objects are frozen' in
path/to/test-splstack.php:4
Stack trace:
#0 path/to/test-splstack.php(4):
SplDoublyLinkedList-setIteratorMode(1)
#1 {main}
  thrown in path/to/test-splstack.php on line 4





-- 
Edit this bug report at http://bugs.php.net/?id=48052edit=1

#48052 [NEW]: SPLStack::setIteratorMode() throw exception on keep/delete flag

2009-04-22 Thread ralph at smashlabs dot com 
From: ralph at smashlabs dot com
Operating system: OSX
PHP version:  5.3.0RC1
PHP Bug Type: SPL related
Bug description:  SPLStack::setIteratorMode() throw exception on keep/delete 
flag

Description:

Attempting to change the IteratorMode throws an exception.

The is probably due to the code that changes the LIFO/FIFO ordering that
is also settable via the inherited method of
SplDoublyLinkedList::setIteratorMode().



Reproduce code:
---
?php

$s = new SPLStack(); 
$s-setIteratorMode(SplDoublyLinkedList::IT_MODE_DELETE);

Expected result:

Do not throw exception on the following use cases:

-setIteratorMode(SplDoublyLinkedList::IT_MODE_DELETE)
-setIteratorMode(SplDoublyLinkedList::IT_MODE_KEEP)

Actual result:
--
PHP Fatal error:  Uncaught exception 'RuntimeException' with message
'Iterators' LIFO/FIFO modes for SplStack/SplQueue objects are frozen' in
path/to/test-splstack.php:4
Stack trace:
#0 path/to/test-splstack.php(4): SplDoublyLinkedList-setIteratorMode(1)
#1 {main}
  thrown in path/to/test-splstack.php on line 4

-- 
Edit bug report at http://bugs.php.net/?id=48052edit=1
-- 
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48052r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48052r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48052r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48052r=fixedcvs
Fixed in CVS and need be documented: 
http://bugs.php.net/fix.php?id=48052r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48052r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=48052r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=48052r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=48052r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=48052r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=48052r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=48052r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=48052r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48052r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=48052r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48052r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=48052r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=48052r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=48052r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=48052r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=48052r=mysqlcfg

#41461 [Bgs-Opn]: E_STRICT notice when overriding methods not defined by an Interface in hierarchy

2007-06-19 Thread ralph at smashlabs dot com 
 ID:   41461
 User updated by:  ralph at smashlabs dot com
-Summary:  Odd E_STRICT notice raised when using Interfaces
 Reported By:  ralph at smashlabs dot com
-Status:   Bogus
+Status:   Open
 Bug Type: Class/Object related
 Operating System: *
 PHP Version:  *
 New Comment:

Marcus,

After re-reading, I didn't think that I was clear in my original bug
report, so I attempted to clarify the matter (2 posts up).  I still
think this is a problem and that it hinders the usage of interfaces as
it restricts concrete classes from overriding methods introduced at the
abstract layer, not the interface layer.

If this is still by design, go ahead and close, but I wanted to make
absolutely sure as most people either do not care about E_STRICT, or
haven't run into the problem yet ;)

Thanks again,
Ralph


Previous Comments:


[2007-05-28 17:53:41] ralph at smashlabs dot com

PS. I did check this with the internals list before I posted.. And I
think you actually confirmed it for me on the list

http://news.php.net/php.internals/29646

Thank you for your time,
-ralph



[2007-05-28 17:42:50] ralph at smashlabs dot com

I am sorry, perhaps I should rephrase (I was rushed when I wrote the
original bug report) and I don't think I was especially clear.

In general, we are speaking strictly of Method Overriding.  PHP
currently allows concrete classes to override methods in abstract
classes as demonstrated by this code:

[EMAIL PROTECTED] ~/tmp $ cat test_method_override.php 
?php

error_reporting(E_ALL | E_STRICT);

class Z_Abstract
{
  public function someFunc($one, $two)
  {  }
}

class Z_Concrete extends Z_Abstract
{
  public function  someFunc($uno, $dos, $tres)
  {  }
}

$o = new Z_Concrete();
[EMAIL PROTECTED] ~/tmp $ php test_method_override.php 
[EMAIL PROTECTED] ~/tmp $ 

As you can see, no E_STRICT was triggered, thus allowing the concrete
class to override the method from the abstract class.

On the other hand, when adding an _empty_ interface to the superclass
hierarchy, the behavior changes.  The simple inclusion of an interface
now (albeit empty) seemingly shouldn't add any complexities to method
overriding for methods outside the scope of the interface itself.  I
have done a bit more homework, and it seems like not alot of IS_A
inheritance literature exists to describe this problem, let alone
justify the behavior we are seeing in practice..  See code:

[EMAIL PROTECTED] ~/tmp $ cat test_method_override2.php 
?php

error_reporting(E_ALL | E_STRICT);

interface Z_Interface
{ }

class Z_Abstract implements Z_Interface
{
  public function someFunc($one, $two)
  {  }
}

class Z_Concrete extends Z_Abstract
{
  public function  someFunc($uno, $dos, $tres)
  {  }
}

$o = new Z_Concrete();
[EMAIL PROTECTED] ~/tmp $ php test_method_override2.php 

Strict standards: Declaration of Z_Concrete::someFunc() should be
compatible with that of Z_Abstract::someFunc() in
/home/webdeveloper/tmp/test_method_override2.php on line 14



At the very least, I looks like one of the two is broken (At least in
the spirit of OOP as it relates to polymorphism and overriding methods.)



[2007-05-28 15:08:50] [EMAIL PROTECTED]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

PHP follows strict is_a inheritance.

By the way, it is called signature and even if you could change it it
would not solve the problem. And anyway it would break inheritance
rules.



[2007-05-21 23:06:13] ralph at smashlabs dot com

Description:

When an interface is a parent of a class, the interface is implying a
specific profile for a given function (here its __get) even though it is
not defined in the interface itself.  This is making it impossible to
overload and/or change the profile of the function in a descendant
class.


Reproduce code:
---
The following will produce this notice:

Strict Standards: Declaration of Z_Concrete::__get() should be
compatible with that of Z_Abstract::__get() in xxx on line 16

?php

error_reporting(E_ALL | E_STRICT);

interface Z_Interface
{ }

abstract class Z_Abstract implements Z_Interface
{
  public function __get($name)
  {
return;
  }
}

class Z_Concrete extends Z_Abstract
{
  public function  __get($name)
  {
return null;
  }
}

$t = new Z_Concrete();





This code will not produce a notice:

?php

error_reporting(E_ALL | E_STRICT);

abstract class Z_Abstract
{
  public function __get($name)
  {
return;
  }
}

class Z_Concrete extends Z_Abstract
{
  public function  __get

#41461 [Bgs]: Odd E_STRICT notice raised when using Interfaces

2007-05-28 Thread ralph at smashlabs dot com 
 ID:   41461
 User updated by:  ralph at smashlabs dot com
 Reported By:  ralph at smashlabs dot com
 Status:   Bogus
 Bug Type: Class/Object related
 Operating System: *
 PHP Version:  *
 New Comment:

I am sorry, perhaps I should rephrase (I was rushed when I wrote the
original bug report) and I don't think I was especially clear.

In general, we are speaking strictly of Method Overriding.  PHP
currently allows concrete classes to override methods in abstract
classes as demonstrated by this code:

[EMAIL PROTECTED] ~/tmp $ cat test_method_override.php 
?php

error_reporting(E_ALL | E_STRICT);

class Z_Abstract
{
  public function someFunc($one, $two)
  {  }
}

class Z_Concrete extends Z_Abstract
{
  public function  someFunc($uno, $dos, $tres)
  {  }
}

$o = new Z_Concrete();
[EMAIL PROTECTED] ~/tmp $ php test_method_override.php 
[EMAIL PROTECTED] ~/tmp $ 

As you can see, no E_STRICT was triggered, thus allowing the concrete
class to override the method from the abstract class.

On the other hand, when adding an _empty_ interface to the superclass
hierarchy, the behavior changes.  The simple inclusion of an interface
now (albeit empty) seemingly shouldn't add any complexities to method
overriding for methods outside the scope of the interface itself.  I
have done a bit more homework, and it seems like not alot of IS_A
inheritance literature exists to describe this problem, let alone
justify the behavior we are seeing in practice..  See code:

[EMAIL PROTECTED] ~/tmp $ cat test_method_override2.php 
?php

error_reporting(E_ALL | E_STRICT);

interface Z_Interface
{ }

class Z_Abstract implements Z_Interface
{
  public function someFunc($one, $two)
  {  }
}

class Z_Concrete extends Z_Abstract
{
  public function  someFunc($uno, $dos, $tres)
  {  }
}

$o = new Z_Concrete();
[EMAIL PROTECTED] ~/tmp $ php test_method_override2.php 

Strict standards: Declaration of Z_Concrete::someFunc() should be
compatible with that of Z_Abstract::someFunc() in
/home/webdeveloper/tmp/test_method_override2.php on line 14



At the very least, I looks like one of the two is broken (At least in
the spirit of OOP as it relates to polymorphism and overriding methods.)


Previous Comments:


[2007-05-28 15:08:50] [EMAIL PROTECTED]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

PHP follows strict is_a inheritance.

By the way, it is called signature and even if you could change it it
would not solve the problem. And anyway it would break inheritance
rules.



[2007-05-21 23:06:13] ralph at smashlabs dot com

Description:

When an interface is a parent of a class, the interface is implying a
specific profile for a given function (here its __get) even though it is
not defined in the interface itself.  This is making it impossible to
overload and/or change the profile of the function in a descendant
class.


Reproduce code:
---
The following will produce this notice:

Strict Standards: Declaration of Z_Concrete::__get() should be
compatible with that of Z_Abstract::__get() in xxx on line 16

?php

error_reporting(E_ALL | E_STRICT);

interface Z_Interface
{ }

abstract class Z_Abstract implements Z_Interface
{
  public function __get($name)
  {
return;
  }
}

class Z_Concrete extends Z_Abstract
{
  public function  __get($name)
  {
return null;
  }
}

$t = new Z_Concrete();





This code will not produce a notice:

?php

error_reporting(E_ALL | E_STRICT);

abstract class Z_Abstract
{
  public function __get($name)
  {
return;
  }
}

class Z_Concrete extends Z_Abstract
{
  public function  __get($name)
  {
return null;
  }
}

$t = new Z_Concrete();

The only difference is that the former has an interface as a parent,
the latter does not.


Expected result:

No E_STRICT notice raised

Actual result:
--
E_STRICT notice raised.





-- 
Edit this bug report at http://bugs.php.net/?id=41461edit=1

#41461 [Bgs]: Odd E_STRICT notice raised when using Interfaces

2007-05-28 Thread ralph at smashlabs dot com 
 ID:   41461
 User updated by:  ralph at smashlabs dot com
 Reported By:  ralph at smashlabs dot com
 Status:   Bogus
 Bug Type: Class/Object related
 Operating System: *
 PHP Version:  *
 New Comment:

PS. I did check this with the internals list before I posted.. And I
think you actually confirmed it for me on the list

http://news.php.net/php.internals/29646

Thank you for your time,
-ralph


Previous Comments:


[2007-05-28 17:42:50] ralph at smashlabs dot com

I am sorry, perhaps I should rephrase (I was rushed when I wrote the
original bug report) and I don't think I was especially clear.

In general, we are speaking strictly of Method Overriding.  PHP
currently allows concrete classes to override methods in abstract
classes as demonstrated by this code:

[EMAIL PROTECTED] ~/tmp $ cat test_method_override.php 
?php

error_reporting(E_ALL | E_STRICT);

class Z_Abstract
{
  public function someFunc($one, $two)
  {  }
}

class Z_Concrete extends Z_Abstract
{
  public function  someFunc($uno, $dos, $tres)
  {  }
}

$o = new Z_Concrete();
[EMAIL PROTECTED] ~/tmp $ php test_method_override.php 
[EMAIL PROTECTED] ~/tmp $ 

As you can see, no E_STRICT was triggered, thus allowing the concrete
class to override the method from the abstract class.

On the other hand, when adding an _empty_ interface to the superclass
hierarchy, the behavior changes.  The simple inclusion of an interface
now (albeit empty) seemingly shouldn't add any complexities to method
overriding for methods outside the scope of the interface itself.  I
have done a bit more homework, and it seems like not alot of IS_A
inheritance literature exists to describe this problem, let alone
justify the behavior we are seeing in practice..  See code:

[EMAIL PROTECTED] ~/tmp $ cat test_method_override2.php 
?php

error_reporting(E_ALL | E_STRICT);

interface Z_Interface
{ }

class Z_Abstract implements Z_Interface
{
  public function someFunc($one, $two)
  {  }
}

class Z_Concrete extends Z_Abstract
{
  public function  someFunc($uno, $dos, $tres)
  {  }
}

$o = new Z_Concrete();
[EMAIL PROTECTED] ~/tmp $ php test_method_override2.php 

Strict standards: Declaration of Z_Concrete::someFunc() should be
compatible with that of Z_Abstract::someFunc() in
/home/webdeveloper/tmp/test_method_override2.php on line 14



At the very least, I looks like one of the two is broken (At least in
the spirit of OOP as it relates to polymorphism and overriding methods.)



[2007-05-28 15:08:50] [EMAIL PROTECTED]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

PHP follows strict is_a inheritance.

By the way, it is called signature and even if you could change it it
would not solve the problem. And anyway it would break inheritance
rules.



[2007-05-21 23:06:13] ralph at smashlabs dot com

Description:

When an interface is a parent of a class, the interface is implying a
specific profile for a given function (here its __get) even though it is
not defined in the interface itself.  This is making it impossible to
overload and/or change the profile of the function in a descendant
class.


Reproduce code:
---
The following will produce this notice:

Strict Standards: Declaration of Z_Concrete::__get() should be
compatible with that of Z_Abstract::__get() in xxx on line 16

?php

error_reporting(E_ALL | E_STRICT);

interface Z_Interface
{ }

abstract class Z_Abstract implements Z_Interface
{
  public function __get($name)
  {
return;
  }
}

class Z_Concrete extends Z_Abstract
{
  public function  __get($name)
  {
return null;
  }
}

$t = new Z_Concrete();





This code will not produce a notice:

?php

error_reporting(E_ALL | E_STRICT);

abstract class Z_Abstract
{
  public function __get($name)
  {
return;
  }
}

class Z_Concrete extends Z_Abstract
{
  public function  __get($name)
  {
return null;
  }
}

$t = new Z_Concrete();

The only difference is that the former has an interface as a parent,
the latter does not.


Expected result:

No E_STRICT notice raised

Actual result:
--
E_STRICT notice raised.





-- 
Edit this bug report at http://bugs.php.net/?id=41461edit=1

#41461 [NEW]: Odd E_STRICT notice raised when using Interfaces

2007-05-21 Thread ralph at smashlabs dot com 
From: ralph at smashlabs dot com
Operating system: Linux
PHP version:  5.2.2
PHP Bug Type: Class/Object related
Bug description:  Odd E_STRICT notice raised when using Interfaces

Description:

When an interface is a parent of a class, the interface is implying a
specific profile for a given function (here its __get) even though it is
not defined in the interface itself.  This is making it impossible to
overload and/or change the profile of the function in a descendant class.


Reproduce code:
---
The following will produce this notice:

Strict Standards: Declaration of Z_Concrete::__get() should be compatible
with that of Z_Abstract::__get() in xxx on line 16

?php

error_reporting(E_ALL | E_STRICT);

interface Z_Interface
{ }

abstract class Z_Abstract implements Z_Interface
{
  public function __get($name)
  {
return;
  }
}

class Z_Concrete extends Z_Abstract
{
  public function  __get($name)
  {
return null;
  }
}

$t = new Z_Concrete();





This code will not produce a notice:

?php

error_reporting(E_ALL | E_STRICT);

abstract class Z_Abstract
{
  public function __get($name)
  {
return;
  }
}

class Z_Concrete extends Z_Abstract
{
  public function  __get($name)
  {
return null;
  }
}

$t = new Z_Concrete();

The only difference is that the former has an interface as a parent, the
latter does not.


Expected result:

No E_STRICT notice raised

Actual result:
--
E_STRICT notice raised.

-- 
Edit bug report at http://bugs.php.net/?id=41461edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=41461r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=41461r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=41461r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41461r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=41461r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=41461r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41461r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41461r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=41461r=support
Expected behavior:http://bugs.php.net/fix.php?id=41461r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=41461r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=41461r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41461r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=41461r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41461r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41461r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=41461r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=41461r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=41461r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41461r=mysqlcfg

#41253 [NEW]: session_start Warnings caught by error handler produce E_Fatal

2007-05-01 Thread ralph at smashlabs dot com 
From: ralph at smashlabs dot com
Operating system: Linux
PHP version:  5.2.1
PHP Bug Type: Session related
Bug description:  session_start Warnings caught by error handler produce E_Fatal

Description:

Abstract: when handling php errors via set_error_handler() with the
intention of throwing a catchable error, an E_FATAL error is triggered.

Details: This is similar to the error you might see when attempting to
throw an exception from an objects destructor.  The internal pointer to the
unwinding stack is lost and/or blown away.

without the error handler session_start with an invalid save_path will
produce an E_WARNING

Reproduce code:
---
?

ini_set('session.save_path', '/var/log'); 
set_error_handler('save_handler', E_ALL); 
try { 
session_start(); 
} catch (Exception $e) { 
echo $e-getMessage(); 
} 

function save_handler($errno, $errmsg) 
{ 
throw new Exception('Error caught and thrown as exception: ' .
$errmsg); 
}  


Expected result:

Error caught and thrown as exception: session_start():
open(/var/log/sess_3e97dad0fe4ce6f285e97593471f2c88, O_RDWR) failed:
Permission denied (13)

Actual result:
--
Error caught and thrown as exception: session_start():
open(/var/log/sess_3e97dad0fe4ce6f285e97593471f2c88, O_RDWR) failed:
Permission denied (13)
Fatal error: Exception thrown without a stack frame in Unknown on line 0

-- 
Edit bug report at http://bugs.php.net/?id=41253edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=41253r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=41253r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=41253r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41253r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=41253r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=41253r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41253r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41253r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=41253r=support
Expected behavior:http://bugs.php.net/fix.php?id=41253r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=41253r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=41253r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41253r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=41253r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41253r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41253r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=41253r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=41253r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=41253r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41253r=mysqlcfg

#40457 [NEW]: ReflectionProperty lacks method getStartLine() / getEndLine()

2007-02-12 Thread ralph at smashlabs dot com 
From: ralph at smashlabs dot com
Operating system: Linux 2.6
PHP version:  5.2.1
PHP Bug Type: Class/Object related
Bug description:  ReflectionProperty lacks method getStartLine() / getEndLine()

Description:

Simply put, when getting a property (in the same manner as a method) from
a class, ReflectionProperty lacks the ability (as does the
ReflectionClass) to retrieve a line number from where the property was
defined.

  - Properties [1] {
Property [ default protected $_Id ]
  }

  - Methods [3] {
Method [ user, overwrites Submission public method get ] {
  @@
/home/webdeveloper/vhosts/zdiis2.dev/development/modeling/models/ZDISubmission.php
11 - 14

  - Parameters [1] {
Parameter #0 [ optional $identifiers = Array ]
  }
}


-- 
Edit bug report at http://bugs.php.net/?id=40457edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=40457r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=40457r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=40457r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=40457r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=40457r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=40457r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=40457r=needscript
Try newer version:http://bugs.php.net/fix.php?id=40457r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=40457r=support
Expected behavior:http://bugs.php.net/fix.php?id=40457r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=40457r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=40457r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=40457r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=40457r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=40457r=dst
IIS Stability:http://bugs.php.net/fix.php?id=40457r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=40457r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=40457r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=40457r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=40457r=mysqlcfg

#6932 [Com]: Filesize / File_exists and include_path

2006-11-08 Thread ralph at smashlabs dot com 
 ID:   6932
 Comment by:   ralph at smashlabs dot com
 Reported By:  richard dot heyes at heyes-computing dot net
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: Any
 PHP Version:  4.0.2
 New Comment:

Why do you guys refuse to add some kind of functionality to the
language that would allow people to test if a file is in the in the
current include path (any of them) and where the file is located
absolutely?  Seriously?

-ralph


Previous Comments:


[2006-04-05 09:30:41] rhoelvis-bell at yahoo dot com

I just think would be great to check before we get any kind of warning
or whatever. And I also think would be of great importance to offer a
clean code and service.



[2006-03-10 02:34:09] admin at microsoft dot com

FIX THIS ASAP PLZ !!!
IS IMPORTANT !!!



[2006-03-08 16:41:34] ericjhollander at yahoo dot com

This is so obvious.  It should be there.  We should be able to do an
easy test BEFORE calling include().



[2006-02-24 22:38:22] arnold at bean-it dot nl

I third that!
And I would also like to see this argument for the function
'is_readable' and 'is_writable'.

Currently there is no clean way to check if a file can be included.
Simply including a file which can't be opened causes a warning to be
triggered. Suppressing include() with an @ is not advisable, since
parse errors won't be displayed, but will cause the script to die,
causing a blank screen. (Happy debugging, hope you're using
ZendStudio).

The best solution I've come up with is:
if (($fp = @fopen($filename, 'r', 1)) and fclose($fp))
include_once($filename);

Anybody reading this bug PLEASE VOTE that this is important to you,
because it doesn't look like anybody is willing to add this (simple)
feature.



[2005-06-30 19:15:44] sr at brightlight dot ch

I second this request.
Open since 5 years, since PHP5's autoload even more important 
and not even yet assigned... :-/



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/6932

-- 
Edit this bug report at http://bugs.php.net/?id=6932edit=1

#38085 [Bgs]: session_regenerate_id() clashes with session.save_path

2006-07-14 Thread ralph at smashlabs dot com 
 ID:   38085
 User updated by:  ralph at smashlabs dot com
 Reported By:  ralph at smashlabs dot com
 Status:   Bogus
 Bug Type: Session related
 Operating System: Linux 2.6 series
 PHP Version:  5.1.4
 New Comment:

You are correct, this is an issue of the internal cwd changing.  This
only seems to be an issue in a forked environment as when started w/
strace and apache2 non-forked it works as expected.  

The fact of the matter is that as a user, I should certainly not be
expected to concern myself with the inner workings of php, its internal
state, or the internal current working directory.  When I supply a
session.save_path in a script, it should be clear that it is being set
within the context of the user-script.  Simply put, PHP should
recognize when a relative directory was passed and prefix it with the
base directory of the calling script.

Since session.save_path related code is so isolated, it seems like it
would be more trivial than not to add this to the
ext/session/mod_files.c or some function that uses the save_path. 
After a quick search, it seems like I am not the only one that has
wanted this functionality:
http://us2.php.net/manual/en/ref.session.php#54881

Furthermore, having this would encourage better PHP (app) coding
standards, resulting in cleaner, more portable solutions.

BTW, nowhere in the manual does it say the path must be absolute.


Previous Comments:


[2006-07-13 13:45:58] [EMAIL PROTECTED]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

The bottom line is that you should not use relative paths as 
they can be affected by internal directory change. Therefor 
throwing you out of the expected directory path resulting in 
the errors you've encountered.



[2006-07-13 05:43:30] ralph at smashlabs dot com

Thanks for the quick response.

For both 5.1.4 and 5.2 that script works fine if I use a full path from
root, eg: /home/ralph/dev/application/var/sessions
(including with a trailing slash too).

In both 5.1.4 and 5.2 the problem persists when you use a relative
path.

Can you not reproduce this?  Shall I post some INI info?

While not super high priority, in a bootstrapped type framework based
envoirment, it would be nice to be able to use relative paths for
portablity reasons.

Thanks again.
Ralph



[2006-07-13 00:03:05] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip

Works fine in latest cvs, even with 10 runs.
Have you tried changing ../application/var/sessions to a full 
path?



[2006-07-12 21:59:44] ralph at smashlabs dot com

Description:

I have not dug super deep into this problem but it seems as though if I
try to call session_regenerate_id() after having set session.save_path
with custom values, i get an error.  My guess is that
session_regenerate_id() is having issues with the save_path var. See
rest below:

Reproduce code:
---
This is my test script:

file: ../htdocs/test.php
?

ini_set(session.save_path, ;666;../application/var/sessions);

session_start();

$id_before = session_id();

if ((++$_SESSION['counter'] % 5) == 0)
{
session_regenerate_id(true);
}

echo preSESSION ID BEFORE:  . $id_before . \n;
echo SESSION ID AFTER :  . session_id();
echo COUNTER  :  . $_SESSION['counter'];

? 

Expected result:

The first 5 times it runs, it works fine... which means the file was
created with the proper permissions and at the proper location.

On the 5th run, I should not see any errors. Only the before and after
Session ID AND there should be a file in the directory with the old
session data... Counter should never start over.



Actual result:
--
SESSION ID BEFORE: 1e1469055dd81c95fb78aafde667639a
SESSION ID AFTER : a51b257a22da32065a0bef114abac7c7

COUNTER  : 5

Warning:  Unknown:
open(../application/var/sessions/sess_a51b257a22da32065a0bef114abac7c7,
O_RDWR) failed: No such file or directory (2) in Unknown on line 0



Warning:  Unknown: Failed to write session data (files). Please verify
that the current setting of session.save_path is correct
(;666;../application/var/sessions) in Unknown on line 0





-- 
Edit this bug report at http://bugs.php.net/?id=38085edit=1

#38085 [NEW]: session_regenerate_id() clashes with session.save_path

2006-07-12 Thread ralph at smashlabs dot com 
From: ralph at smashlabs dot com
Operating system: Linux 2.6 series
PHP version:  5.1.4
PHP Bug Type: Session related
Bug description:  session_regenerate_id() clashes with session.save_path

Description:

I have not dug super deep into this problem but it seems as though if I
try to call session_regenerate_id() after having set session.save_path
with custom values, i get an error.  My guess is that
session_regenerate_id() is having issues with the save_path var. See rest
below:

Reproduce code:
---
This is my test script:

file: ../htdocs/test.php
?

ini_set(session.save_path, ;666;../application/var/sessions);

session_start();

$id_before = session_id();

if ((++$_SESSION['counter'] % 5) == 0)
{
session_regenerate_id(true);
}

echo preSESSION ID BEFORE:  . $id_before . \n;
echo SESSION ID AFTER :  . session_id();
echo COUNTER  :  . $_SESSION['counter'];

? 

Expected result:

The first 5 times it runs, it works fine... which means the file was
created with the proper permissions and at the proper location.

On the 5th run, I should not see any errors. Only the before and after
Session ID AND there should be a file in the directory with the old
session data... Counter should never start over.



Actual result:
--
SESSION ID BEFORE: 1e1469055dd81c95fb78aafde667639a
SESSION ID AFTER : a51b257a22da32065a0bef114abac7c7

COUNTER  : 5

Warning:  Unknown:
open(../application/var/sessions/sess_a51b257a22da32065a0bef114abac7c7,
O_RDWR) failed: No such file or directory (2) in Unknown on line 0



Warning:  Unknown: Failed to write session data (files). Please verify
that the current setting of session.save_path is correct
(;666;../application/var/sessions) in Unknown on line 0

-- 
Edit bug report at http://bugs.php.net/?id=38085edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=38085r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=38085r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=38085r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38085r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=38085r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=38085r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38085r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38085r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=38085r=support
Expected behavior:http://bugs.php.net/fix.php?id=38085r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=38085r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=38085r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38085r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=38085r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38085r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38085r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=38085r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=38085r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=38085r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38085r=mysqlcfg

#38085 [Fbk-Opn]: session_regenerate_id() clashes with session.save_path

2006-07-12 Thread ralph at smashlabs dot com 
 ID:   38085
 User updated by:  ralph at smashlabs dot com
 Reported By:  ralph at smashlabs dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Session related
 Operating System: Linux 2.6 series
 PHP Version:  5.1.4
 New Comment:

Thanks for the quick response.

For both 5.1.4 and 5.2 that script works fine if I use a full path from
root, eg: /home/ralph/dev/application/var/sessions
(including with a trailing slash too).

In both 5.1.4 and 5.2 the problem persists when you use a relative
path.

Can you not reproduce this?  Shall I post some INI info?

While not super high priority, in a bootstrapped type framework based
envoirment, it would be nice to be able to use relative paths for
portablity reasons.

Thanks again.
Ralph


Previous Comments:


[2006-07-13 00:03:05] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip

Works fine in latest cvs, even with 10 runs.
Have you tried changing ../application/var/sessions to a full 
path?



[2006-07-12 21:59:44] ralph at smashlabs dot com

Description:

I have not dug super deep into this problem but it seems as though if I
try to call session_regenerate_id() after having set session.save_path
with custom values, i get an error.  My guess is that
session_regenerate_id() is having issues with the save_path var. See
rest below:

Reproduce code:
---
This is my test script:

file: ../htdocs/test.php
?

ini_set(session.save_path, ;666;../application/var/sessions);

session_start();

$id_before = session_id();

if ((++$_SESSION['counter'] % 5) == 0)
{
session_regenerate_id(true);
}

echo preSESSION ID BEFORE:  . $id_before . \n;
echo SESSION ID AFTER :  . session_id();
echo COUNTER  :  . $_SESSION['counter'];

? 

Expected result:

The first 5 times it runs, it works fine... which means the file was
created with the proper permissions and at the proper location.

On the 5th run, I should not see any errors. Only the before and after
Session ID AND there should be a file in the directory with the old
session data... Counter should never start over.



Actual result:
--
SESSION ID BEFORE: 1e1469055dd81c95fb78aafde667639a
SESSION ID AFTER : a51b257a22da32065a0bef114abac7c7

COUNTER  : 5

Warning:  Unknown:
open(../application/var/sessions/sess_a51b257a22da32065a0bef114abac7c7,
O_RDWR) failed: No such file or directory (2) in Unknown on line 0



Warning:  Unknown: Failed to write session data (files). Please verify
that the current setting of session.save_path is correct
(;666;../application/var/sessions) in Unknown on line 0





-- 
Edit this bug report at http://bugs.php.net/?id=38085edit=1