#37060 [NEW]: Type of retval of Countable::count() is not checked

2006-04-12 Thread alpha at rrs dot at
From: alpha at rrs dot at
Operating system: 
PHP version:  5.1.2
PHP Bug Type: SPL related
Bug description:  Type of retval of Countable::count() is not checked

Description:

If an implementation of Countable::count() does not return an 
int the result is a big, random number. It seems like the 
result is always taken as int even if it's a string or float.

IMHO the result should get typecasted to an int or at least a 
warning. If I typecast the result to an int in the return 
statement it works as expected. 

Reproduce code:
---
?php

error_reporting(E_ALL | E_STRICT);

class Test implements Countable {
function count() {
return '1';
}
}

$test = new Test();
var_dump(count($test));

?

Expected result:

int(1)


Actual result:
--
int(148313044)


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


#27356 [Opn-Csd]: sleep() doesn't return unslept seconds

2004-11-10 Thread alpha at rrs dot at
 ID:   27356
 User updated by:  alpha at rrs dot at
 Reported By:  alpha at rrs dot at
-Status:   Open
+Status:   Closed
 Bug Type: Feature/Change Request
 Operating System: Unix
 PHP Version:  4.3.4
 New Comment:

Seems like the bug got fixed in CVS last week by andrey:
http://cvs.php.net/php-src/ext/standard/basic_functions.c

As it seems like noone'll find my bug (see #27841) I'll close it
myself.


Previous Comments:


[2004-02-22 19:18:12] alpha at rrs dot at

Description:

The C function sleep() is defined as:
unsigned int sleep(unsigned int seconds); 

In PHP it is defined as:
void sleep ( int seconds)

The Problem is when using a CLI with a signal handler sleep() ends
immediately but doesn't return the unslept seconds, thus it's not
possible to resleep.
Checked current CVS via cvs.php.net and there is still no return value.
So it's not a documentation problem.

Reproduce code:
---
php -r var_dump(sleep(10));

Expected result:

int(0) or unslept seconds if a signal was handled

Actual result:
--
NULL





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


#27356 [NEW]: sleep() doesn't return unslept seconds

2004-02-22 Thread alpha at rrs dot at
From: alpha at rrs dot at
Operating system: Unix
PHP version:  4.3.4
PHP Bug Type: Feature/Change Request
Bug description:  sleep() doesn't return unslept seconds

Description:

The C function sleep() is defined as:

unsigned int sleep(unsigned int seconds); 



In PHP it is defined as:

void sleep ( int seconds)



The Problem is when using a CLI with a signal handler sleep() ends
immediately but doesn't return the unslept seconds, thus it's not possible
to resleep.

Checked current CVS via cvs.php.net and there is still no return value. So
it's not a documentation problem.

Reproduce code:
---
php -r var_dump(sleep(10));

Expected result:

int(0) or unslept seconds if a signal was handled

Actual result:
--
NULL

-- 
Edit bug report at http://bugs.php.net/?id=27356edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=27356r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=27356r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=27356r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=27356r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27356r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=27356r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=27356r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27356r=support
Expected behavior:  http://bugs.php.net/fix.php?id=27356r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27356r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27356r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=27356r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27356r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=27356r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=27356r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27356r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27356r=float


#22190 [Com]: Renaming some files

2004-02-02 Thread alpha at rrs dot at
 ID:   22190
 Comment by:   alpha at rrs dot at
 Reported By:  mill_2k at eml dot cc
 Status:   Closed
 Bug Type: *General Issues
 Operating System: Windows
 PHP Version:  5CVS
 New Comment:

If I see things correctly it's still not possible to use a differtent
ini-file for if php4 and php5 share the same apache server under
win32.
It's not possible with the registry key as both use the same. It's not
possible with a enviroment variable as both use the same. It's not
possible with a php.ini in the apache dir as both use the same. It's
not possible with the SAPI-name as both are named apache. If php.ini is
in the same directory as the php5apache.dll it's ignored.
A different ini is important as modules for php4 crashes php5 in
php5ts.dll


Previous Comments:


[2004-01-17 07:55:39] [EMAIL PROTECTED]

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.





[2003-10-20 06:18:48] [EMAIL PROTECTED]

It's not that simple, really. :)
Here's a list of some files that need to be renamed:

php4.spec.in - php.spec.in
sapi/apache2*/sapi_apache2.c - mod_php4.c and mod_php5.c

And dozens of *.dsp files need to be modified (and maybe renamed too in
some cases)




[2003-10-20 05:41:03] nvivo at mandic dot com dot br

Wow, this is really urgent!

I think it's easy to solve this one, isn't it?

I remember Zend Survey about PHP and most people use windows to develop
in PHP. Like me, tons of people have an apache or IIS installed on
win2k/xp to run and test scripts at home or work.

I really want to test/use this new version of php, but i can't install
in the same instance of apache as module and i don't want to run 2
servers in different ports or use it as cgi... the best would be run
*.php5 with php5...

This thread is open since february... we are in october.. come on, is
it really so hard to change the name of 3 files??



[2003-10-13 08:31:51] nicobn at virtualisp dot qc dot ca

A workarround for the .ini problem is to setup two different paths for
each PHP installation, so one is in /usr/lib and the other is in
/usr/local/lib (for exemple).



[2003-09-30 19:30:41] rpanning at hotmail dot com

Also would be nice if the ini file was named php5.ini instead of just
php.ini. This way we could have both php 4 and 5 installed and not have
ini conflicts.

Also just wandering if there is a timeline for this fix.



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

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