#45575 [NEW]: Segfault with invalid non-string as event handler callback
From: chris_se at gmx dot net Operating system: Irrelevant PHP version: 5.2.6 PHP Bug Type: InterBase related Bug description: Segfault with invalid non-string as event handler callback Description: Same problem as with bug #4 - just for a different extension: The interbase extension accepts arbitrary zvals as callbacks (which is fine) but always uses Z_STRVAL(zval) to display an error message if the callback is invalid. This will cause a segfault if e.g. int(1) is passed as a callback. The following patch against PHP_5_3 (it also applies against PHP 5.2) solves the problem (there are two places where error messages are generated): http://www.christian-seiler.de/temp/ibase-5.3.patch And the same patch ported to HEAD: http://www.christian-seiler.de/temp/ibase-6.patch Please note that I only found this bug because I did a source review of all core extensions that call callbacks in order to ensure they are compatible with closures. I have no knowledge or experience whatsoever with Interbase or Firebird so I can't actually test this. But by reading the source it is clear that this will crash PHP (see bug #4 where the same problem occurred but where I could test the issue). Reproduce code: --- Probably something like: ibase_set_event_handler($connection, 1, whatever); Expected result: Callback argument 1 is not a callable function Actual result: -- Segmentation fault. -- Edit bug report at http://bugs.php.net/?id=45575edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45575r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45575r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45575r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45575r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45575r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45575r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45575r=needscript Try newer version:http://bugs.php.net/fix.php?id=45575r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45575r=support Expected behavior:http://bugs.php.net/fix.php?id=45575r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45575r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45575r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45575r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45575r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45575r=dst IIS Stability:http://bugs.php.net/fix.php?id=45575r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45575r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45575r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45575r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45575r=mysqlcfg
#45555 [NEW]: Segfault with invalid non-string as register_introspection_callback
From: chris_se at gmx dot net
Operating system: Irrelevant
PHP version: 5.2.6
PHP Bug Type: XMLRPC-EPI related
Bug description: Segfault with invalid non-string as
register_introspection_callback
Description:
If an invalid callback is passed to the
xmlrpc_server_register_introspection_callback method, the method builds an
error message in which it uses Z_STRVAL(php_function) where php_function
may be an arbitrary zval (for example, an integer). But accepting arbitrary
zvals is necessary because callbacks may be arrays or objects.
This may lead to two problems:
1) Segfaults if something which when interpreted as a pointer in the zval
struct is an invalid memory address.
2) Reading arbitrary process memory if an integer is passed that
corresponds to a valid memory address.
This does represent a very minor security problem (denial of service in
case (1) and reading sensitive data from other process parts in case of (2)
and e.g. a threaded webserver).
I've written patches for PHP 5.3 and PHP 6 that solve this problem. The
patch for PHP 5.3 doesn't apply to the PHP 5.2 branch but backporting
should be trivial:
http://www.christian-seiler.de/temp/xmlrpc-bug-5.3.patch
http://www.christian-seiler.de/temp/xmlrpc-bug-6.patch
Reproduce code:
---
?php
$options = array ();
$request = xmlrpc_encode_request (system.describeMethods, $options);
$server = xmlrpc_server_create ();
xmlrpc_server_register_introspection_callback ($server, 1);
$options = array ('output_type' = 'xml', 'version' = 'xmlrpc');
xmlrpc_server_call_method ($server, $request, NULL, $options)
?
other variant --
?php
define (VALID_MEM_ADDR, 0xXX);
$options = array ();
$request = xmlrpc_encode_request (system.describeMethods, $options);
$server = xmlrpc_server_create ();
xmlrpc_server_register_introspection_callback ($server, VALID_MEM_ADDR);
$options = array ('output_type' = 'xml', 'version' = 'xmlrpc');
xmlrpc_server_call_method ($server, $request, NULL, $options)
?
Expected result:
Warning: xmlrpc_server_call_method(): Error calling user introspection
callback: 1() in %s on line 7
other variant --
Warning: xmlrpc_server_call_method(): Error calling user introspection
callback: 0xXX() in %s on line 7
Actual result:
--
Segmentation fault
other variant --
Warning: xmlrpc_server_call_method(): Error calling user introspection
callback: [Contents of string found at the specified memory address]() in
%s on line 7
--
Edit bug report at http://bugs.php.net/?id=4edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=4r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=4r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=4r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=4r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=4r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=4r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=4r=needscript
Try newer version:http://bugs.php.net/fix.php?id=4r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=4r=support
Expected behavior:http://bugs.php.net/fix.php?id=4r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=4r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=4r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=4r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=4r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=4r=dst
IIS Stability:http://bugs.php.net/fix.php?id=4r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=4r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=4r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=4r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=4r=mysqlcfg
#43182 [Opn]: file_put_contents' LOCK_EX flag is useless with advisory locking
ID: 43182
User updated by: chris_se at gmx dot net
Reported By: chris_se at gmx dot net
Status: Open
Bug Type: Streams related
Operating System: Any POSIX-compatible OS
PHP Version: 5.2.4
New Comment:
Oh, I forgot:
There's a solution for this problem that is quite a bit easier as the
other one I suggested:
ALWAYS open the file in append mode and truncate it AFTER acquiring the
lock. Normally this has the drawback that the append mode does NOT have
the same semantics as the write mode (i.e. using fseek to reposition the
write pointer won't work as the contents will always be appended to the
end of the file) but that doesn't matter here since a) with ftruncate()
the end of the file will be at byte zero and b) file_put_contents only
writes out the complete data and does not need to reposition the write
pointer of the file.
Well, at least with normal C and fopen(3) it's not that complicated,
with PHP's streams API it gets complicated again because some stream
wrappers don't support truncating of a file (e.g. the FTP wrapper).
Those don't support locking either, so that wouldn't be a problem anyway
except that it's as far as I could see not possible to determine whether
truncating the file will be possible BEFORE opening it.
Anyway, here's a patch against the PHP 5.2 branch that fixes this bug:
===
RCS file: /repository/php-src/ext/standard/file.c,v
retrieving revision 1.409.2.6.2.28
diff -u -r1.409.2.6.2.28 file.c
--- ext/standard/file.c 4 Sep 2007 12:51:49 - 1.409.2.6.2.28
+++ ext/standard/file.c 6 Nov 2007 18:49:48 -
@@ -604,16 +604,44 @@
context = php_stream_context_from_zval(zcontext, flags
PHP_FILE_NO_DEFAULT_CONTEXT);
- stream = php_stream_open_wrapper_ex(filename, (flags
PHP_FILE_APPEND) ? ab : wb,
+ // open in append mode and truncate later with LOCK_EX
+ // note that this will cause the stream to be closed and opened
again
+ // if truncating is not supported - but there is no way with
the
+ // current streams API to check before actually opening the
file
+ stream = php_stream_open_wrapper_ex(filename, (flags
PHP_FILE_APPEND || flags LOCK_EX) ? ab : wb,
((flags PHP_FILE_USE_INCLUDE_PATH) ? USE_PATH
: 0) | ENFORCE_SAFE_MODE | REPORT_ERRORS, NULL, context);
if (stream == NULL) {
RETURN_FALSE;
}
+ // worst-case scenario: user wanted LOCK_EX but the stream
can't be
+ // truncated. So, reopen in 'wb' mode and ignore locking
+ // (TODO: possibly generate a warning that LOCK_EX wasn't
possible with
+ // this stream?)
+ if (!(flags PHP_FILE_APPEND) (flags LOCK_EX)
!php_stream_truncate_supported(stream)) {
+ php_stream_close(stream);
+ stream = php_stream_open_wrapper_ex(filename, wb,
+ ((flags PHP_FILE_USE_INCLUDE_PATH) ?
USE_PATH : 0) | ENFORCE_SAFE_MODE | REPORT_ERRORS, NULL, context);
+ // remove LOCK_EX flag - locking will be useless now
anyway
+ // (we just truncated the file)
+ flags = flags ~LOCK_EX;
+ }
if (flags LOCK_EX (!php_stream_supports_lock(stream) ||
php_stream_lock(stream, LOCK_EX))) {
php_stream_close(stream);
RETURN_FALSE;
}
+
+ // if the file was to be locked and not to be opened in append
mode,
+ // we now need to truncate it (we already checked for truncate
support
+ // and reopened the stream and removed LOCK_EX if it wasn't
available)
+ if (!(flags PHP_FILE_APPEND) (flags LOCK_EX)) {
+ if (php_stream_truncate_set_size(stream, 0)) {
+ // we couldn't truncate the stream even though
+ // truncating was supported
+ php_stream_close(stream);
+ RETURN_FALSE;
+ }
+ }
switch (Z_TYPE_P(data)) {
case IS_RESOURCE:
===
It is a bit ugly because of the problem described above: It can only be
determined whether it's possible to truncate the file after it was
opened, so if it's not, it has to be closed and opened again. The
function remains functional in any case, just causes a little additional
overhead if a stream wrapper without file truncation support (e.g. FTP)
AND LOCK_EX are used together.
So, you have four possibilities now:
1) Use the patch as-is.
2) Improve the patch by somehow detecting truncate support before
opening the file (and therefore removing the need to reopen the file if
such a wrapper is used in combination with LOCK_EX).
3) Add the already mentioned file mode that doesn't include O_TRUNC
4) Remove the LOCK_EX flag from file_put_contents alltogether.
Previous Comments
#43182 [WFx]: file_put_contents' LOCK_EX flag is useless with advisory locking
ID: 43182
User updated by: chris_se at gmx dot net
Reported By: chris_se at gmx dot net
Status: Wont fix
Bug Type: Streams related
Operating System: Any POSIX-compatible OS
PHP Version: 5.2.4
New Comment:
Excuse me, I don't intend to sound rude - but did you even read my
report? I never even mentioned O_EXCL and it has NOTHING to do with the
problem I reported.
To summarize the problem again (and perhaps make myself clearer):
file_put_contents has - according to the documentation - a third
parameter called $flags. In the documentation, it is stated, that the
LOCK_EX constant may be passed as a flag. The documentation for
file_put_contents states:
LOCK_EX: Acquire an exclusive lock on the file while proceeding to
the writing.
So, one may assume that the file will be locked exclusively BEFORE
writing to it.
Now, the problem is, that this is not the case! Have a look at
ext/standard/file.c:
http://cvs.php.net/viewvc.cgi/php-src/ext/standard/file.c?revision=1.409.2.6.2.27view=markup
There you see this line of code:
stream = php_stream_open_wrapper_ex(filename, (flags
PHP_FILE_APPEND) ? ab : wb,
((flags PHP_FILE_USE_INCLUDE_PATH) ? USE_PATH : 0) |
ENFORCE_SAFE_MODE | REPORT_ERRORS, NULL, context);
Followed by that line:
if (flags LOCK_EX (!php_stream_supports_lock(stream) ||
php_stream_lock(stream, LOCK_EX))) {
So, what does this code do? (if FILE_APPEND was not specified)
1) It openes the file in 'wb' mode for writing.
2) It locks the file exclusively
3) THEN it actually starts writing the file contents
So, the problem actually is the following:
'wb' as a fopen(3) mode translates to O_WRONLY | O_CREAT | O_TRUNC as
an open(2) mode. What does that do? It truncates the file UPON OPENING
IT! And AFTER THAT it tries to acquire the lock. Since locks on
POSIX-compatible systems are advisory (flock(2) anyway), any possible
other lock on the file will NOT be honoured by file_put_contents and the
$flag == LOCK_EX parameter is completely ineffective.
Please, have a look at my test case - it's really simple. One PHP
script opens the file for reading, acquires a shared lock and goes to
sleep. If the other PHP script is executed in the mean time, the file is
opened and then the other script tries to acquire an exclusive lock on
the same file - and has to wait until the first script releases it.
That's fine. But what's not fine is that prior to acquiring the
exclusive lock it has ALREADY modified the file! So after the first
script returns from it's sleeping phase, it will see an empty file
because it was truncated by the other script upon opening.
What the CURRENT PHP code translates to is basically:
int fd = open ('file.txt', O_WRONLY | O_CREAT | O_TRUNC, 0666);
flock (fd, LOCK_EX);
Which causes exactly the described problems.
And there IS a solution for this. The following C code CORRECTLY
acquires an exclusive lock for writing to a file WITHOUT truncating it
before it is safe to do so:
int fd = open ('file.txt', O_WRONLY | O_CREAT, 0666);
flock (fd, LOCK_EX);
ftruncate (fd, 0);
// now write something to fd
This is absolutely correct in POSIX and completely portable (assuming
flock(2) is provided by the OS, but if fcntl(2) is used as a
replacement, it does not change anything).
So now the ONLY question remains: How is it possible to integrate that
fix with PHP code?
And that is a bit more tricky than the mere C code becaues PHP uses
fopen(3)-style file modes for the stream wrapper API instead of numeric
file modes as provided by open(2). And there is currently no
fopen(3)-style file mode translating to O_WRONLY | O_CREAT.
So, I see two possible solutions:
* Add another fopen(3) style file mode that does exactly that.
* Remove the LOCK_EX flag from file_put_contents completely.
It DOES NOT make sense to keep the flag but leave this bug unfixed,
because
a) It is utterly and completely useless with advisory locking.
Keeping it will only cause people who read the documentation
to assume it's safe to use the flag - which is plainly WRONG.
b) If mandatory locking is used (i.e. when using Windows), the
OTHER LOCK that is already in place on the file will take care
for the data consistency, i.e. a lock created by another
program will delay the truncating of the file until AFTER the
lock is released. The exclusive lock created on the file itself
will have NO interaction with any other lock in place prior to
the file_put_contents_call.
Previous Comments:
[2007-11-04 15:30:54] [EMAIL PROTECTED]
On *nix systems O_CREAT and O_EXCL are mutually exclusive and will
prevent creation of a file if one already exists. Therefore lock needs
to be created separately or you need to create another file on the same
disk and then use atomic rename
#43182 [WFx-Csd]: file_put_contents' LOCK_EX flag is useless with advisory locking
ID: 43182
User updated by: chris_se at gmx dot net
Reported By: chris_se at gmx dot net
-Status: Wont fix
+Status: Closed
Bug Type: Streams related
Operating System: Any POSIX-compatible OS
PHP Version: 5.2.4
New Comment:
Closed to reopen the bug.
Previous Comments:
[2007-11-04 16:12:02] chris_se at gmx dot net
Excuse me, I don't intend to sound rude - but did you even read my
report? I never even mentioned O_EXCL and it has NOTHING to do with the
problem I reported.
To summarize the problem again (and perhaps make myself clearer):
file_put_contents has - according to the documentation - a third
parameter called $flags. In the documentation, it is stated, that the
LOCK_EX constant may be passed as a flag. The documentation for
file_put_contents states:
LOCK_EX: Acquire an exclusive lock on the file while proceeding to
the writing.
So, one may assume that the file will be locked exclusively BEFORE
writing to it.
Now, the problem is, that this is not the case! Have a look at
ext/standard/file.c:
http://cvs.php.net/viewvc.cgi/php-src/ext/standard/file.c?revision=1.409.2.6.2.27view=markup
There you see this line of code:
stream = php_stream_open_wrapper_ex(filename, (flags
PHP_FILE_APPEND) ? ab : wb,
((flags PHP_FILE_USE_INCLUDE_PATH) ? USE_PATH : 0) |
ENFORCE_SAFE_MODE | REPORT_ERRORS, NULL, context);
Followed by that line:
if (flags LOCK_EX (!php_stream_supports_lock(stream) ||
php_stream_lock(stream, LOCK_EX))) {
So, what does this code do? (if FILE_APPEND was not specified)
1) It openes the file in 'wb' mode for writing.
2) It locks the file exclusively
3) THEN it actually starts writing the file contents
So, the problem actually is the following:
'wb' as a fopen(3) mode translates to O_WRONLY | O_CREAT | O_TRUNC as
an open(2) mode. What does that do? It truncates the file UPON OPENING
IT! And AFTER THAT it tries to acquire the lock. Since locks on
POSIX-compatible systems are advisory (flock(2) anyway), any possible
other lock on the file will NOT be honoured by file_put_contents and the
$flag == LOCK_EX parameter is completely ineffective.
Please, have a look at my test case - it's really simple. One PHP
script opens the file for reading, acquires a shared lock and goes to
sleep. If the other PHP script is executed in the mean time, the file is
opened and then the other script tries to acquire an exclusive lock on
the same file - and has to wait until the first script releases it.
That's fine. But what's not fine is that prior to acquiring the
exclusive lock it has ALREADY modified the file! So after the first
script returns from it's sleeping phase, it will see an empty file
because it was truncated by the other script upon opening.
What the CURRENT PHP code translates to is basically:
int fd = open ('file.txt', O_WRONLY | O_CREAT | O_TRUNC, 0666);
flock (fd, LOCK_EX);
Which causes exactly the described problems.
And there IS a solution for this. The following C code CORRECTLY
acquires an exclusive lock for writing to a file WITHOUT truncating it
before it is safe to do so:
int fd = open ('file.txt', O_WRONLY | O_CREAT, 0666);
flock (fd, LOCK_EX);
ftruncate (fd, 0);
// now write something to fd
This is absolutely correct in POSIX and completely portable (assuming
flock(2) is provided by the OS, but if fcntl(2) is used as a
replacement, it does not change anything).
So now the ONLY question remains: How is it possible to integrate that
fix with PHP code?
And that is a bit more tricky than the mere C code becaues PHP uses
fopen(3)-style file modes for the stream wrapper API instead of numeric
file modes as provided by open(2). And there is currently no
fopen(3)-style file mode translating to O_WRONLY | O_CREAT.
So, I see two possible solutions:
* Add another fopen(3) style file mode that does exactly that.
* Remove the LOCK_EX flag from file_put_contents completely.
It DOES NOT make sense to keep the flag but leave this bug unfixed,
because
a) It is utterly and completely useless with advisory locking.
Keeping it will only cause people who read the documentation
to assume it's safe to use the flag - which is plainly WRONG.
b) If mandatory locking is used (i.e. when using Windows), the
OTHER LOCK that is already in place on the file will take care
for the data consistency, i.e. a lock created by another
program will delay the truncating of the file until AFTER the
lock is released. The exclusive lock created on the file itself
will have NO interaction with any other lock in place prior to
the file_put_contents_call.
[2007-11-04 15:30:54] [EMAIL PROTECTED]
On *nix systems O_CREAT and O_EXCL are mutually exclusive and will
prevent creation of a file if one already exists. Therefore lock
#43182 [Csd-Opn]: file_put_contents' LOCK_EX flag is useless with advisory locking
ID: 43182
User updated by: chris_se at gmx dot net
Reported By: chris_se at gmx dot net
-Status: Closed
+Status: Open
Bug Type: Streams related
Operating System: Any POSIX-compatible OS
PHP Version: 5.2.4
New Comment:
Reopened.
Previous Comments:
[2007-11-04 22:11:43] chris_se at gmx dot net
Closed to reopen the bug.
[2007-11-04 16:12:02] chris_se at gmx dot net
Excuse me, I don't intend to sound rude - but did you even read my
report? I never even mentioned O_EXCL and it has NOTHING to do with the
problem I reported.
To summarize the problem again (and perhaps make myself clearer):
file_put_contents has - according to the documentation - a third
parameter called $flags. In the documentation, it is stated, that the
LOCK_EX constant may be passed as a flag. The documentation for
file_put_contents states:
LOCK_EX: Acquire an exclusive lock on the file while proceeding to
the writing.
So, one may assume that the file will be locked exclusively BEFORE
writing to it.
Now, the problem is, that this is not the case! Have a look at
ext/standard/file.c:
http://cvs.php.net/viewvc.cgi/php-src/ext/standard/file.c?revision=1.409.2.6.2.27view=markup
There you see this line of code:
stream = php_stream_open_wrapper_ex(filename, (flags
PHP_FILE_APPEND) ? ab : wb,
((flags PHP_FILE_USE_INCLUDE_PATH) ? USE_PATH : 0) |
ENFORCE_SAFE_MODE | REPORT_ERRORS, NULL, context);
Followed by that line:
if (flags LOCK_EX (!php_stream_supports_lock(stream) ||
php_stream_lock(stream, LOCK_EX))) {
So, what does this code do? (if FILE_APPEND was not specified)
1) It openes the file in 'wb' mode for writing.
2) It locks the file exclusively
3) THEN it actually starts writing the file contents
So, the problem actually is the following:
'wb' as a fopen(3) mode translates to O_WRONLY | O_CREAT | O_TRUNC as
an open(2) mode. What does that do? It truncates the file UPON OPENING
IT! And AFTER THAT it tries to acquire the lock. Since locks on
POSIX-compatible systems are advisory (flock(2) anyway), any possible
other lock on the file will NOT be honoured by file_put_contents and the
$flag == LOCK_EX parameter is completely ineffective.
Please, have a look at my test case - it's really simple. One PHP
script opens the file for reading, acquires a shared lock and goes to
sleep. If the other PHP script is executed in the mean time, the file is
opened and then the other script tries to acquire an exclusive lock on
the same file - and has to wait until the first script releases it.
That's fine. But what's not fine is that prior to acquiring the
exclusive lock it has ALREADY modified the file! So after the first
script returns from it's sleeping phase, it will see an empty file
because it was truncated by the other script upon opening.
What the CURRENT PHP code translates to is basically:
int fd = open ('file.txt', O_WRONLY | O_CREAT | O_TRUNC, 0666);
flock (fd, LOCK_EX);
Which causes exactly the described problems.
And there IS a solution for this. The following C code CORRECTLY
acquires an exclusive lock for writing to a file WITHOUT truncating it
before it is safe to do so:
int fd = open ('file.txt', O_WRONLY | O_CREAT, 0666);
flock (fd, LOCK_EX);
ftruncate (fd, 0);
// now write something to fd
This is absolutely correct in POSIX and completely portable (assuming
flock(2) is provided by the OS, but if fcntl(2) is used as a
replacement, it does not change anything).
So now the ONLY question remains: How is it possible to integrate that
fix with PHP code?
And that is a bit more tricky than the mere C code becaues PHP uses
fopen(3)-style file modes for the stream wrapper API instead of numeric
file modes as provided by open(2). And there is currently no
fopen(3)-style file mode translating to O_WRONLY | O_CREAT.
So, I see two possible solutions:
* Add another fopen(3) style file mode that does exactly that.
* Remove the LOCK_EX flag from file_put_contents completely.
It DOES NOT make sense to keep the flag but leave this bug unfixed,
because
a) It is utterly and completely useless with advisory locking.
Keeping it will only cause people who read the documentation
to assume it's safe to use the flag - which is plainly WRONG.
b) If mandatory locking is used (i.e. when using Windows), the
OTHER LOCK that is already in place on the file will take care
for the data consistency, i.e. a lock created by another
program will delay the truncating of the file until AFTER the
lock is released. The exclusive lock created on the file itself
will have NO interaction with any other lock in place prior to
the file_put_contents_call.
[2007-11-04 15:30:54] [EMAIL PROTECTED]
On *nix
#43182 [NEW]: file_put_contents' LOCK_EX flag is useless with advisory locking
From: chris_se at gmx dot net
Operating system: Any POSIX-compatible OS
PHP version: 5.2.4
PHP Bug Type: Streams related
Bug description: file_put_contents' LOCK_EX flag is useless with advisory
locking
Description:
The LOCK_EX flag of file_put_contents suggests that the function will use
an advisory lock to ensure transaction safety. This is NOT the case (except
when combined with FILE_APPEND). It actually DOES request an exclusive lock
on the file but only does so AFTER opening it in the 'wb' mode which will
truncate the file on opening BEFORE the actual lock can be acquired.
The correct behaviour would be to open the file for writing without
truncating it, in C for example using
int fileno = open (file, O_WRONLY | O_CREAT, 0666);
(WITHOUT adding O_TRUNC!), THEN acquiring the lock using flock() and THEN
truncating the file to 0 bytes length.
I don't know if there's a simple possibility to integrate it with the
current streams API (since there's no fopen mode that will map to either
O_WRONLY | O_CREAT or O_RWDR | O_CREAT) but if it's not possible to fix it,
you should at least remove the option, since it suggests something it can't
provide with advisory locking.
This is not a problem on Windows since Windows locks are always mandatory.
Reproduce code:
---
First script (start in in a first window using any P):
?php
file_put_contents ('file.txt', 'Hello World!');
$f = fopen ('file.txt', 'r') or die (Could not open file!\n);
flock ($f, LOCK_SH) or die (Could not acaquire lock!\n);
echo Sleeping for 20 seconds (please use file_put_contents script in the
mean time!)\n;
sleep (20);
$x .= fread ($f, 1024);
fclose ($f);
echo Contents was: ' . $x . '\n;
?
Second script (start it in a second window in the same directory while the
first one is sleeping):
?php
file_put_contents ('file.txt', 'ByeBye Joe!', LOCK_EX);
?
Expected result:
The first script should output:
Sleeping for 20 seconds (please use file_put_contents script in the mean
time!)
Contents was: 'Hello World!'
Actual result:
--
The first script outputs:
Sleeping for 20 seconds (please use file_put_contents script in the mean
time!)
Contents was: ''
--
Edit bug report at http://bugs.php.net/?id=43182edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43182r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43182r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43182r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43182r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43182r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43182r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43182r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43182r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43182r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43182r=support
Expected behavior:http://bugs.php.net/fix.php?id=43182r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43182r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43182r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43182r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43182r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43182r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43182r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43182r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43182r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43182r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43182r=mysqlcfg
#42294 [Com]: round will not use PHP_ROUND_FUZZ on 64bit CPUs
ID: 42294
Comment by: chris_se at gmx dot net
Reported By: oliver at teqneers dot de
Status: Assigned
Bug Type: *Configuration Issues
Operating System: OpenSuSE 10.2
PHP Version: 5.2.4RC1
Assigned To: iliaa
New Comment:
I just read this bug report and wanted to add a few things. Rounding
floating point numbers is anything but trivial.
The core issue is that certain numbers which are representable with
only a finite amount of digits in the decimal system are not necessarily
representable with a finite amount of digits in the binary system. The
number 0.285 in this bug report is an example for that: In the binary
system, its representation is periodic - just as 1/3 can only be
displayed as a periodic number (0.3...) in the decimal system.
Since a floating point number only supports a finite number of digits,
the period is cut off and therefore the number 0.285 stored as a float
is not exactly 0.285 but slightly smaller, you can try it yourself:
2
?php
$f = 0.285;
printf(%.20f\n, $f);
?
0.28497558
(The exact representation may vary depending on how percise the
floating point unit in your processor is.)
Another number 1.285 mentioned in this thread also has the same
problem:
?php
$f = 1.285;
printf(%.20f\n, $f);
?
1.28492006
Now, the traditional rounding method in the decimal system is to take
the lower number for the digits 0, 1, 2, 3 and 4 and the higher number
for the digits 5, 6, 7, 8 and 9. So 1.4 becomes 1 and 1.5 becomes 2 if
rounded to zero digits precision.
The problem is that if the internal representation of the floating
point number is 0.2849...something instead of 0.285, the rounding
algorithm will incorrectly assume the last digit is a 4 and not a 5 and
then return the lower number instead of the higher one.
Now one may ask why does 1.285 work and 0.285 doesn't if both are not
representable using finite digits in the binary system? This is due to
the way the rounding algorithm works: It first multiplies the numbers by
10 to the power of the places of precision (with 2 places precision, it
multiplies them with 100) and then it rounds to the next integer. Now,
if you have a look at the representation of 1.285 * 100 and 0.285 * 100,
you will get:
?php
$f = 1.285 * 100;
printf(%.20f\n, $f);
$f = 0.285 * 100;
printf(%.20f\n, $f);
?
128.5000
28.49644729
Of course, one might argue that 28.5 is infact representable as a
floating point number - sure, but that does not matter the computer
always calculates with floating point numbers - so in the case of 128.5
the computer actually makes two errors due to decreased precision: The
first is not being able to correctly represent 1.285 and the second is
to accidentally compensate that error due to lack of precision. With
0.285, only the first error happens and so the result is incorrect.
So that's the reason why round() does not always work as expected. Now
there are two possibilities to solve this:
1) Don't give a shit about the error and simply calculate as before.
This is what the Linux implementation of the C99 function round(3) does
(and probably the C99 standard itself, but I don't know since I haven't
looked into it).
2) Try to correct the error: This is what the PHP_ROUND_FUZZ code is
fore. A bit of background: A round() function is available in C only
from C99 onwards - to ensure compability, PHP does rounding manually
using floor/ceil. In order to keep this post short, I'll just look at
positive numbers. So the current implementation of PHP's round() as
found in ext/standard/math.c does the following:
#define PHP_ROUND_WITH_FUZZ(val, places) { \
double tmp_val=val, f = pow(10.0, (double) places); \
tmp_val *= f; \
if (tmp_val = 0.0) { \
tmp_val = floor(tmp_val + PHP_ROUND_FUZZ); \
} else {\
tmp_val = ceil(tmp_val - PHP_ROUND_FUZZ); \
} \
tmp_val /= f; \
val = !zend_isnan(tmp_val) ? tmp_val : val; \
} \
Let's assume for a moment that PHP_ROUND_FUZZ is 0.5, then the code is
obvious: 0.5 is added to the number and then floor() is called. That
will produce the identical result for positive numbers as round() does.
Now, a possible correction for the rounding error is setting
PHP_ROUND_FUZZ to 0.501 - the last digit 1 does just enough to
make round() work as expected.
Obviously, this code has one minor drawback: If one wants to round
0.499 to 0 places precision, the corrected function will
incorrectly return 1 instead of 0 here. On the other hand, this tiny
fuzz will correct the VAST majority of other cases where round() fails.
So, now - what does
#26854 [NEW]: Using ! as a delimiter for regexps will not allow neg. lookahead assertions
From: chris_se at gmx dot net
Operating system: Linux
PHP version: 4.3.4
PHP Bug Type: PCRE related
Bug description: Using ! as a delimiter for regexps will not allow neg. lookahead
assertions
Description:
When I try to use ! as delimiter and use a negative lookahead assertion
which is normally started with (?!, (?! of course does not work, because
the ! will terminate the pattern (and PHP will of course complain). But
when I try to escape the exclamation mark like (?\!, an error occurs.
I assume the \ is not removed in front of the ! after the pattern is freed
from its delimiters.
Reproduce code:
---
$res = preg_match (!^(?\\!foo)[a-z]{3}$!, bar);
Expected result:
$res contains true
Actual result:
--
Warning: Compilation failed: unrecognized character after (? at offset 3
in /home/christian/- on line 2
--
Edit bug report at http://bugs.php.net/?id=26854edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26854r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26854r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26854r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26854r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26854r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=26854r=needscript
Try newer version: http://bugs.php.net/fix.php?id=26854r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26854r=support
Expected behavior: http://bugs.php.net/fix.php?id=26854r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26854r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26854r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26854r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26854r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26854r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26854r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26854r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26854r=float
#26854 [Bgs]: Using ! as a delimiter for regexps will not allow neg. lookahead assertions
ID: 26854
User updated by: chris_se at gmx dot net
Reported By: chris_se at gmx dot net
Status: Bogus
Bug Type: PCRE related
Operating System: Linux
PHP Version: 4.3.4
New Comment:
Even if this is not a bug (in my eyes, it still is), it is at least a
documentation problem:
From http://www.php.net/manual/en/ref.pcre.php:
--
The syntax for patterns used in these functions closely resembles Perl.
The expression should be enclosed in the delimiters, a forward slash
(/), for example. Any character can be used for delimiter as long as
it's not alphanumeric or backslash (\). If the delimiter character has
to be used in the expression itself, it needs to be escaped by
backslash.
--
From reading this text passage, it is perfectly valid to assume that
what I have assumed.
Previous Comments:
[2004-01-09 12:57:59] [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
Use a different delimiter instead. The library does not remove
backslashes before delimiters and PCRE doesn't know what to do with
(?\\!).
[2004-01-09 12:39:04] chris_se at gmx dot net
Description:
When I try to use ! as delimiter and use a negative lookahead assertion
which is normally started with (?!, (?! of course does not work,
because the ! will terminate the pattern (and PHP will of course
complain). But when I try to escape the exclamation mark like (?\!, an
error occurs.
I assume the \ is not removed in front of the ! after the pattern is
freed from its delimiters.
Reproduce code:
---
$res = preg_match (!^(?\\!foo)[a-z]{3}$!, bar);
Expected result:
$res contains true
Actual result:
--
Warning: Compilation failed: unrecognized character after (? at offset
3 in /home/christian/- on line 2
--
Edit this bug report at http://bugs.php.net/?id=26854edit=1
#24693 [Bgs-Opn]: session.use_trans_sid should changeable by scripts
ID: 24693
User updated by: chris_se at gmx dot net
Reported By: chris_se at gmx dot net
-Status: Bogus
+Status: Open
Bug Type: Feature/Change Request
Operating System: GNU/Linux
PHP Version: 4.3.2
New Comment:
I tried to figure out myself how this could be solved. I just changed
the definition of session.use_trans_sid to PHP_INI_ALL and I recompiled
my PHP module.
Now, I can change session.use_trans_sid before session_start() is
called and it works fine.
Here's the 'patch' (against PHP 4.3.2):
-
--- ext/session/session.c.old 2003-07-19 12:29:58.0 +0200
+++ ext/session/session.c 2003-07-19 12:34:31.0 +0200
@@ -151,7 +151,7 @@
STD_PHP_INI_ENTRY(session.entropy_length, 0,
PHP_INI_ALL, OnUpdateInt,entropy_length, php_ps_globals,
ps_globals)
STD_PHP_INI_ENTRY(session.cache_limiter, nocache,
PHP_INI_ALL, OnUpdateString, cache_limiter, php_ps_globals,
ps_globals)
STD_PHP_INI_ENTRY(session.cache_expire, 180,
PHP_INI_ALL, OnUpdateInt,cache_expire, php_ps_globals,
ps_globals)
- STD_PHP_INI_BOOLEAN(session.use_trans_sid,0,
PHP_INI_SYSTEM|PHP_INI_PERDIR, OnUpdateBool, use_trans_sid,
php_ps_globals,ps_globals)
+ STD_PHP_INI_BOOLEAN(session.use_trans_sid,0,
PHP_INI_ALL, OnUpdateBool, use_trans_sid, php_ps_globals,
ps_globals)
/* Commented out until future discussion */
/* PHP_INI_ENTRY(session.encode_sources, globals,track,
PHP_INI_ALL, NULL) */
-
Previous Comments:
[2003-07-18 09:39:27] chris_se at gmx dot net
Why is that so? In my eyes, the point that makes sense for the rewriter
to be started, is session_start().
Furthermore: If I kind of 'deactivate' the rewriter by ini_set
('url_rewriter.tags', ''); it also has effect on links that were
already sent to output:
---
?php
session_start ();
?
a href=a.phpTest/a
?php
ini_set ('url_rewriter.tags', '');
?
a href=a.phpTest/a
---
will generate:
a href=a.phpTest/a
a href=a.phpTest/a
whereas
---
?php
session_start ();
?
a href=a.phpTest/a
?php
// ini_set ('url_rewriter.tags', '');
?
a href=a.phpTest/a
---
appends the session id to both links.
Therefore I don't quite understand why deactivating the rewriter before
session_start() is not possible whereas modifying it is even possible
after session_start() and even after output that has to be rewritten
was already generated.
[2003-07-18 09:24:20] [EMAIL PROTECTED]
The decision to enable the rewriter is made before your script starts
running.
Once it has started it cannot be turned off again.
[2003-07-18 08:13:21] chris_se at gmx dot net
May I also ask why this is not possible?
[2003-07-17 21:35:01] [EMAIL PROTECTED]
Not possible.
[2003-07-17 12:57:04] chris_se at gmx dot net
Description:
According to http://de3.php.net/manual/de/function.ini-set.php you may
not alter session.use_trans_sid in PHP scripts, because it is only
changeable in PHP_INI_SYSTEM|PHP_INI_PERDIR.
I do not know why this is so, but in my eyes it should at least be
possible to deactivate this option at runtime.
Reproduce code:
---
?php
ini_set ('session.use_trans_sid', 0);
session_start ();
?
a href=a.phpTest/a
Expected result:
In an environment with 'session.use_trans_sid' activated in the php.ini
file or in a .htaccess file, it should *not* append the session id to
the link:
a href=a.phpTest/a
Actual result:
--
The session id is appended to the link and not even an error or notice
ist produced:
a href=a.php?PHPSESSID=...Test/a
--
Edit this bug report at http://bugs.php.net/?id=24693edit=1
#24693 [Opn]: session.use_trans_sid should changeable by scripts
ID: 24693
User updated by: chris_se at gmx dot net
Reported By: chris_se at gmx dot net
Status: Open
Bug Type: Feature/Change Request
Operating System: GNU/Linux
PHP Version: 4.3.2
New Comment:
as there is no mechanism for ini_set to check whether output has
started
There is a mechanism: these OnUpdate*-functions. I added a function
OnUpdateTransSid which is essentially the OnUpdateBool function
definied within Zend/zend_ini.c but with an if-block in front of it, if
the session was already started. (the if-block was taken from another
OnUpdate-function that was in session.c)
It probably would be cleaner to call OnUpdateBool directly instead of
just copying the code, but as all those functions are defined by
precompiler macros, I assume the parameters of these functios could
change, so just copying the code from OnUpdateBool seems to be more
portable to me.
Here are my changes so far: (tested with PHP 4.3.2)
---
--- ext/session/session.c.old 2003-07-19 12:29:58.0 +0200
+++ ext/session/session.c 2003-07-19 13:46:33.0 +0200
@@ -105,6 +105,32 @@
return SUCCESS;
}
+static PHP_INI_MH(OnUpdateTransSid)
+{
+ if (PS(session_status) == php_session_active) {
+ php_error_docref(NULL TSRMLS_CC, E_WARNING, A session is active.
You cannot change the session module's ini settings at this time.);
+ return FAILURE;
+ }
+
+ zend_bool *p;
+#ifndef ZTS
+ char *base = (char *) mh_arg2;
+#else
+ char *base;
+
+ base = (char *) ts_resource(*((int *) mh_arg2));
+#endif
+
+ p = (zend_bool *) (base+(size_t) mh_arg1);
+
+ if (strncasecmp(on, new_value, sizeof(on))) {
+ *p = (zend_bool) atoi(new_value);
+ } else {
+ *p = (zend_bool) 1;
+ }
+ return SUCCESS;
+}
+
static PHP_INI_MH(OnUpdateSerializer)
{
if (PS(session_status) == php_session_active) {
@@ -151,7 +177,7 @@
STD_PHP_INI_ENTRY(session.entropy_length, 0,
PHP_INI_ALL, OnUpdateInt,entropy_length, php_ps_globals,
ps_globals)
STD_PHP_INI_ENTRY(session.cache_limiter, nocache,
PHP_INI_ALL, OnUpdateString, cache_limiter, php_ps_globals,
ps_globals)
STD_PHP_INI_ENTRY(session.cache_expire, 180,
PHP_INI_ALL, OnUpdateInt,cache_expire, php_ps_globals,
ps_globals)
- STD_PHP_INI_BOOLEAN(session.use_trans_sid,0,
PHP_INI_SYSTEM|PHP_INI_PERDIR, OnUpdateBool, use_trans_sid,
php_ps_globals,ps_globals)
+ STD_PHP_INI_BOOLEAN(session.use_trans_sid,0,
PHP_INI_ALL, OnUpdateTransSid, use_trans_sid, php_ps_globals,
ps_globals)
/* Commented out until future discussion */
/* PHP_INI_ENTRY(session.encode_sources, globals,track,
PHP_INI_ALL, NULL) */
---
Previous Comments:
[2003-07-19 06:20:13] alan at akbkhome dot com
see http://bugs.php.net/bug.php?id=14991
- this wont really fix it
I agree it's a feature request - it would have to be a function like
session_use_transid(true|false) as there is no mechanism for ini_set to
check whether output has started...
[2003-07-19 05:45:10] chris_se at gmx dot net
I tried to figure out myself how this could be solved. I just changed
the definition of session.use_trans_sid to PHP_INI_ALL and I recompiled
my PHP module.
Now, I can change session.use_trans_sid before session_start() is
called and it works fine.
Here's the 'patch' (against PHP 4.3.2):
-
--- ext/session/session.c.old 2003-07-19 12:29:58.0 +0200
+++ ext/session/session.c 2003-07-19 12:34:31.0 +0200
@@ -151,7 +151,7 @@
STD_PHP_INI_ENTRY(session.entropy_length, 0,
PHP_INI_ALL, OnUpdateInt,entropy_length, php_ps_globals,
ps_globals)
STD_PHP_INI_ENTRY(session.cache_limiter, nocache,
PHP_INI_ALL, OnUpdateString, cache_limiter, php_ps_globals,
ps_globals)
STD_PHP_INI_ENTRY(session.cache_expire, 180,
PHP_INI_ALL, OnUpdateInt,cache_expire, php_ps_globals,
ps_globals)
- STD_PHP_INI_BOOLEAN(session.use_trans_sid,0,
PHP_INI_SYSTEM|PHP_INI_PERDIR, OnUpdateBool, use_trans_sid,
php_ps_globals,ps_globals)
+ STD_PHP_INI_BOOLEAN(session.use_trans_sid,0,
PHP_INI_ALL, OnUpdateBool, use_trans_sid, php_ps_globals,
ps_globals)
/* Commented out until future discussion */
/* PHP_INI_ENTRY(session.encode_sources, globals,track,
PHP_INI_ALL, NULL
#24693 [Bgs]: session.use_trans_sid should changeable by scripts
ID: 24693
User updated by: chris_se at gmx dot net
Reported By: chris_se at gmx dot net
Status: Bogus
Bug Type: Feature/Change Request
Operating System: GNU/Linux
PHP Version: 4.3.2
New Comment:
May I also ask why this is not possible?
Previous Comments:
[2003-07-17 21:35:01] [EMAIL PROTECTED]
Not possible.
[2003-07-17 12:57:04] chris_se at gmx dot net
Description:
According to http://de3.php.net/manual/de/function.ini-set.php you may
not alter session.use_trans_sid in PHP scripts, because it is only
changeable in PHP_INI_SYSTEM|PHP_INI_PERDIR.
I do not know why this is so, but in my eyes it should at least be
possible to deactivate this option at runtime.
Reproduce code:
---
?php
ini_set ('session.use_trans_sid', 0);
session_start ();
?
a href=a.phpTest/a
Expected result:
In an environment with 'session.use_trans_sid' activated in the php.ini
file or in a .htaccess file, it should *not* append the session id to
the link:
a href=a.phpTest/a
Actual result:
--
The session id is appended to the link and not even an error or notice
ist produced:
a href=a.php?PHPSESSID=...Test/a
--
Edit this bug report at http://bugs.php.net/?id=24693edit=1
#24693 [Bgs]: session.use_trans_sid should changeable by scripts
ID: 24693
User updated by: chris_se at gmx dot net
Reported By: chris_se at gmx dot net
Status: Bogus
Bug Type: Feature/Change Request
Operating System: GNU/Linux
PHP Version: 4.3.2
New Comment:
Why is that so? In my eyes, the point that makes sense for the rewriter
to be started, is session_start().
Furthermore: If I kind of 'deactivate' the rewriter by ini_set
('url_rewriter.tags', ''); it also has effect on links that were
already sent to output:
---
?php
session_start ();
?
a href=a.phpTest/a
?php
ini_set ('url_rewriter.tags', '');
?
a href=a.phpTest/a
---
will generate:
a href=a.phpTest/a
a href=a.phpTest/a
whereas
---
?php
session_start ();
?
a href=a.phpTest/a
?php
// ini_set ('url_rewriter.tags', '');
?
a href=a.phpTest/a
---
appends the session id to both links.
Therefore I don't quite understand why deactivating the rewriter before
session_start() is not possible whereas modifying it is even possible
after session_start() and even after output that has to be rewritten
was already generated.
Previous Comments:
[2003-07-18 09:24:20] [EMAIL PROTECTED]
The decision to enable the rewriter is made before your script starts
running.
Once it has started it cannot be turned off again.
[2003-07-18 08:13:21] chris_se at gmx dot net
May I also ask why this is not possible?
[2003-07-17 21:35:01] [EMAIL PROTECTED]
Not possible.
[2003-07-17 12:57:04] chris_se at gmx dot net
Description:
According to http://de3.php.net/manual/de/function.ini-set.php you may
not alter session.use_trans_sid in PHP scripts, because it is only
changeable in PHP_INI_SYSTEM|PHP_INI_PERDIR.
I do not know why this is so, but in my eyes it should at least be
possible to deactivate this option at runtime.
Reproduce code:
---
?php
ini_set ('session.use_trans_sid', 0);
session_start ();
?
a href=a.phpTest/a
Expected result:
In an environment with 'session.use_trans_sid' activated in the php.ini
file or in a .htaccess file, it should *not* append the session id to
the link:
a href=a.phpTest/a
Actual result:
--
The session id is appended to the link and not even an error or notice
ist produced:
a href=a.php?PHPSESSID=...Test/a
--
Edit this bug report at http://bugs.php.net/?id=24693edit=1
#24693 [NEW]: session.use_trans_sid should changeable by scripts
From: chris_se at gmx dot net
Operating system: GNU/Linux
PHP version: 4.3.2
PHP Bug Type: Feature/Change Request
Bug description: session.use_trans_sid should changeable by scripts
Description:
According to http://de3.php.net/manual/de/function.ini-set.php you may not
alter session.use_trans_sid in PHP scripts, because it is only changeable
in PHP_INI_SYSTEM|PHP_INI_PERDIR.
I do not know why this is so, but in my eyes it should at least be
possible to deactivate this option at runtime.
Reproduce code:
---
?php
ini_set ('session.use_trans_sid', 0);
session_start ();
?
a href=a.phpTest/a
Expected result:
In an environment with 'session.use_trans_sid' activated in the php.ini
file or in a .htaccess file, it should *not* append the session id to the
link:
a href=a.phpTest/a
Actual result:
--
The session id is appended to the link and not even an error or notice ist
produced:
a href=a.php?PHPSESSID=...Test/a
--
Edit bug report at http://bugs.php.net/?id=24693edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24693r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24693r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=24693r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24693r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24693r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24693r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24693r=support
Expected behavior: http://bugs.php.net/fix.php?id=24693r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24693r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24693r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24693r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24693r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24693r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24693r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24693r=gnused
