Re: [PHP-DEV] [PATCH] Add configuration value to enable/disable stack trace logging

Am 17.06.19 um 21:27 schrieb Björn Larsson: Den 2019-06-17 kl. 19:10, skrev Erik Lundin: Background: The latest version of PHP seems to handle fatal errors as exceptions which results in stack traces being logged. Stack traces can potentially contain sensitive information and should not be log

Re: [PHP-DEV] [PATCH] Add configuration value to enable/disable stack trace logging

Joe’s solution seems to fix the problem. I havent tested it yet though. I would have been forced to patch this reguardless before bringing php 7+ into production. His fix would be enough to protect the data provided proper config files are enforced. Thanks Joe! Hopefully this will be merged wh

Re: [PHP-DEV] [PATCH] Add configuration value to enable/disable stack trace logging

Den 2019-06-17 kl. 19:10, skrev Erik Lundin: Background: The latest version of PHP seems to handle fatal errors as exceptions which results in stack traces being logged. Stack traces can potentially contain sensitive information and should not be logged in a production environment. Test code

[PHP-DEV] [PATCH] Add configuration value to enable/disable stack trace logging

Background: The latest version of PHP seems to handle fatal errors as exceptions which results in stack traces being logged. Stack traces can potentially contain sensitive information and should not be logged in a production environment. Test code: Jun 17 15:58:01 server php[29650]: PHP Fatal

[PHP-DEV] [PATCH] Raw logging to syslog

Background: In newer versions of PHP the syslog logging is forced to multiline logging and it's not possible to turn this off. This is especially problematic when you have a lot of logging and need to search and find connected lines from a single call to syslog(). For example when debugging mul

[PHP-DEV] patch for imap bug 77153

Hi! I've checked in the patch for https://bugs.php.net/bug.php?id=77153, which disables by default rsh/ssh login functionality in IMAP. I assume most people neither know such functionality existed nor need it, but still it's a BC break. The reason why I did it is because IMAP library does not vali

Re: [PHP-DEV] [PATCH] Implementing array_every() and array_any()

On Mon, Oct 22, 2018 at 1:39 AM Levi Morrison wrote: > > On Sun, Oct 21, 2018 at 10:04 PM bugreportuser > wrote: > > > > Hi everyone, > > > > A patch for array_every() and array_any() was abandoned from inactivity, > > so I wrote a new patch for it: > > > > https://github.com/php/php-src/pull/359

Re: [PHP-DEV] [PATCH] Implementing array_every() and array_any()

On Sun, Oct 21, 2018 at 10:04 PM bugreportuser wrote: > > Hi everyone, > > A patch for array_every() and array_any() was abandoned from inactivity, > so I wrote a new patch for it: > > https://github.com/php/php-src/pull/3597 > > There was never an internals@ discussion that I can find, but there

Re: [PHP-DEV] [PATCH] Implementing array_every() and array_any()

On Sun, Oct 21, 2018 at 11:03 PM bugreportuser wrote: > A patch for array_every() and array_any() was abandoned from inactivity, > so I wrote a new patch for it: > > https://github.com/php/php-src/pull/3597 > > There was never an internals@ discussion that I can find, but there are > some comments

[PHP-DEV] [PATCH] Implementing array_every() and array_any()

Hi everyone, A patch for array_every() and array_any() was abandoned from inactivity, so I wrote a new patch for it: https://github.com/php/php-src/pull/3597 There was never an internals@ discussion that I can find, but there are some comments on the old pull request. Most of what I changed was

Re: [PHP-DEV] [PATCH] new function for real local date

Hey Ruud. Am 13.03.18 um 20:18 schrieb ruud.bak...@caiway.nl: > As there is no function for getting a real local date for day names and month > names, I wrote a function for that. Maybe an option for a new PHP version? > > > function localdate(string $format, int $timestamp, string $locale) {

[PHP-DEV] [PATCH] new function for real local date

As there is no function for getting a real local date for day names and month names, I wrote a function for that. Maybe an option for a new PHP version? with kind regards, Ruud Bakker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Patch for bug #65312: Segmentation fault with filesize=4096

Hi, > -Original Message- > From: Richard H Lee [mailto:ricardohenry...@gmail.com] > Sent: Thursday, May 11, 2017 3:18 PM > To: internals@lists.php.net > Subject: [PHP-DEV] Patch for bug #65312: Segmentation fault with filesize=4096 > > I submitted a patch for bug

[PHP-DEV] Patch for bug #65312: Segmentation fault with filesize=4096

I submitted a patch for bug #65312 "Segmentation fault with filesize=4096". It's to do with the way Cygwin handles mmap()ing. It is not a duplicate of another bug as marked, it is specific to Cygwin. I'm not sure about the release structure of PHP, but it would be great if I could get this pat

Re: [PHP-DEV] [PATCH] Make var_export() output "(object)array(..."instead of "stdClass::__set_state(..." for stdClass

Hi Marc, Marc Bennewitz wrote: Personally I would like to have a more reasonable way in general. No special case and no magic method. So my proposal then would be to try to add a class cast operator (needs an own RFC) and later to with this approach on var_export. I've wondered if this would

Re: [PHP-DEV] [PATCH] Make var_export() output "(object)array(..." instead of "stdClass::__set_state(..." for stdClass

Hi! > Additionally I feel that adding methods to stdClass will muddy the waters > -- for example, this means that extending stdClass is no longer entirely > unreasonable, as you might want to do it to reuse the __set_state() > implementation. Not something I want to see happening. I'm afraid that

Re: [PHP-DEV] [PATCH] Make var_export() output "(object)array(..." instead of "stdClass::__set_state(..." for stdClass

On Tue, Mar 14, 2017 at 11:20 PM, Derick Rethans wrote: > On Tue, 14 Mar 2017, Andrea Faulds wrote: > > > Hi everyone, > > > > Since stdClass has no __set_state method, var_export() produces unusable > > output if given an object of that class. I wrote a patch that would make > > var_export() pro

Re: [PHP-DEV] [PATCH] Make var_export() output "(object)array(..." instead of "stdClass::__set_state(..." for stdClass

On Tue, 14 Mar 2017, Andrea Faulds wrote: > Hi everyone, > > Since stdClass has no __set_state method, var_export() produces unusable > output if given an object of that class. I wrote a patch that would make > var_export() produce a cast to object instead, which could be evaluated to get > back

Re: [PHP-DEV] [PATCH] Make var_export() output "(object)array(..." instead of "stdClass::__set_state(..." for stdClass

Am 14.03.2017 um 20:26 schrieb Fleshgrinder: On 3/14/2017 7:57 PM, Andrea Faulds wrote: Hi everyone, Since stdClass has no __set_state method, var_export() produces unusable output if given an object of that class. I wrote a patch that would make var_export() produce a cast to object instead,

Re: [PHP-DEV] [PATCH] Make var_export() output "(object)array(..." instead of "stdClass::__set_state(..." for stdClass

On 3/14/2017 7:57 PM, Andrea Faulds wrote: > Hi everyone, > > Since stdClass has no __set_state method, var_export() produces unusable > output if given an object of that class. I wrote a patch that would make > var_export() produce a cast to object instead, which could be evaluated > to get back

[PHP-DEV] [PATCH] Make var_export() output "(object)array(..." instead of "stdClass::__set_state(..." for stdClass

Hi everyone, Since stdClass has no __set_state method, var_export() produces unusable output if given an object of that class. I wrote a patch that would make var_export() produce a cast to object instead, which could be evaluated to get back a stdClass: https://github.com/php/php-src/pull/2

[PHP-DEV] [PATCH] opcache bug #69090, prepend user identifier to keys

Hello, I'm CCing Dmitry Stogov as maintainer because he's listed as an author in ext/opcache/ZendAccelerator.c and has recent commits. I've attached a patch for bug #69090. You can find a more detailed writeup at https://bugs.php.net/bug.php?id=69090 . In short, the patch adds EUID or Window

[PHP-DEV] [Patch] Extension tests fail on dynamic ext dependency

Hi, could someone validate and, if considered OK, merge the following PR: https://github.com/php/php-src/pull/1602 This is a follow-up to a previous patch by Derick to enable testing extensions with a dependency to another (dynamic) extension. More details in the corresponding bug report :

Re: [PHP-DEV] [PATCH] random_int: Fix power of two check.

On Sun, May 10, 2015 at 12:40 PM, Lauri Kenttä wrote: > (x & ~x) is always 0. > ((x & (~x + 1)) != x) works. > ((x & (x - 1)) != 0) works too. > --- > ext/standard/random.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/ext/standard/random.c b/ext/standard/random.c > in

[PHP-DEV] [PATCH] random_int: Fix power of two check.

(x & ~x) is always 0. ((x & (~x + 1)) != x) works. ((x & (x - 1)) != 0) works too. --- ext/standard/random.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ext/standard/random.c b/ext/standard/random.c index 12c2503..4a1adbf 100644 --- a/ext/standard/random.c +++ b/ext/standar

[PHP-DEV] [PATCH] Tick functions (on C level) with state

Hi, I would like to hear comments about a small change to the low-level tick functionality (main/php_ticks.c) to add state to when calling a C tick function The patch is alive at : http://pastebin.com/0zhVNxaY Currently a C tick function gets as a parameter just the number of ticks, and can'

Re: [PHP-DEV] [PATCH] Fix potential int overflow in date extension.

On Tue, 20 Jan 2015, Joshua Rogers wrote: > On 20/01/15 06:15, Joshua Rogers wrote: > > -- > > ext/date/lib/tm2unixtime.c | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > Somebody please take a look at /ext/date/lib/parse_tz.c too: > > 438timelib_sll timelib_get_current_offset(t

Re: [PHP-DEV] [PATCH] Check the return value of do_fstat() to avoid error conditions.

On 27/01/15 14:32, Joshua Rogers wrote: > if '1' is returned, the it is OK to continue. > If '0' is returned, it is not OK to continue(return -1) > > > Since this is the case, should the do_fstat function be changed to a > boolean? https://github.com/php/php-src/pull/1031 -- -- Joshua Rogers

Re: [PHP-DEV] [PATCH] Check the return value of do_fstat() to avoid error conditions.

On 27/01/15 11:39, Joshua Rogers wrote: > if(do_fstat(data, 1)<0) { > return -1; > } This was wrong, anyways. if '1' is returned, the it is OK to continue. If '0' is returned, it is not OK to continue(return -1) Since this is the case, should the do_fstat function be changed to a boolean? It is

Re: [PHP-DEV] [PATCH] Check the return value of do_fstat() to avoid error conditions.

Hi Joshua, On Tue, Jan 27, 2015 at 9:39 AM, Joshua Rogers wrote: > > This patch seems reasonable. Does anyone taking care of this? > Perhaps it should be > > if(do_fstat(data, 1)<0) { > return -1; > } > > just to conform with the rest of the code If nobody is taking care of this yet, please se

Re: [PHP-DEV] [PATCH] Check the return value of do_fstat() to avoid error conditions.

On 27/01/15 11:35, Yasuo Ohgaki wrote: > This patch seems reasonable. Does anyone taking care of this? Perhaps it should be if(do_fstat(data, 1)<0) { return -1; } just to conform with the rest of the code -- -- Joshua Rogers signature.asc Description: OpenPGP digital

Re: [PHP-DEV] [PATCH] Check the return value of do_fstat() to avoid error conditions.

Hi all, On Thu, Jan 15, 2015 at 5:04 PM, Joshua Rogers wrote: > main/streams/plain_wrapper.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/main/streams/plain_wrapper.c b/main/streams/plain_wrapper.c > index f52383d..72be0b0 100644 > --- a/main/streams/plain_wrapper.

Re: [PHP-DEV] [PATCH] Fix integer overflow in calender.

On 27/01/15 11:30, Yasuo Ohgaki wrote: > Hi Joshua, > > Did you send PR or bug report for this? > We need PR or bug report for a bug fix. > Thank you. https://github.com/php/php-src/pull/1009 https://github.com/php/php-src/pull/1008 -- -- Joshua Rogers signature.asc De

Re: [PHP-DEV] [PATCH] Fix integer overflow in calender.

Hi Joshua, Did you send PR or bug report for this? We need PR or bug report for a bug fix. Thank you. -- Yasuo Ohgaki yohg...@ohgaki.net On Mon, Jan 19, 2015 at 8:34 PM, Joshua Rogers wrote: > Fix in overflows in conversation functions for calendar. > Add tests for the overflows. > --- > ext/

Re: [PHP-DEV] [PATCH] Fix potential int overflow in date extension.

Hi all, On Tue, Jan 20, 2015 at 4:23 AM, Joshua Rogers wrote: > On 20/01/15 06:15, Joshua Rogers wrote: > > -- > > ext/date/lib/tm2unixtime.c | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > Somebody please take a look at /ext/date/lib/parse_tz.c too: > > 438timelib_sll timelib

Re: [PHP-DEV] [PATCH] Fix uninitalized variables reads. See CWE-457 for more info.

On 22/01/15 21:36, Yasuo Ohgaki wrote: > > Could you send pull request from github? https://github.com/php/php-src/pull/1012 > It's not required strictly, but if you can includes tests, it would be > great. No tests. It is "undefined behaviour." Thanks, -- -- Joshua Rogers

Re: [PHP-DEV] [PATCH] Fix uninitalized variables reads. See CWE-457 for more info.

Hi Joshua, On Wed, Jan 21, 2015 at 5:28 AM, Joshua Rogers wrote: > ext/mbstring/mbstring.c | 8 > ext/reflection/php_reflection.c | 1 + > main/main.c | 1 + > 3 files changed, 6 insertions(+), 4 deletions(-) > > diff --git a/ext/mbstring/mbstring.c b/ext/mb

Re: [PHP-DEV] [PATCH 2/3] Fix null pointer dereference

Hi, On 22/01/15 13:47, Xinchen Hui wrote: > myabe, you could send these patch via bugs.php.net, or github PR? > > it's better than mails :) Yes, I also submit them to php-src. - https://github.com/php/php-src/pull/1014 I send them to internals@ for if people want to comment on it. But, as suggested

Re: [PHP-DEV] [PATCH 2/3] Fix null pointer dereference

Hey: On Thu, Jan 22, 2015 at 2:27 AM, Joshua Rogers wrote: > --- > > These issues are not serious(only triggerable by the runner/caller of the PHP > program), so no need to make them private. > > sapi/litespeed/lsapi_main.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

[PHP-DEV] [PATCH 3/3] Further improvements in litespeed

--- These issues are not serious(only triggerable by the runner/caller of the PHP program), so no need to make them private. sapi/litespeed/lsapi_main.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sapi/litespeed/lsapi_main.c b/sapi/litespeed/lsapi_main.c index d767306..8144706 100644 -

[PHP-DEV] [PATCH 2/3] Fix null pointer dereference

--- These issues are not serious(only triggerable by the runner/caller of the PHP program), so no need to make them private. sapi/litespeed/lsapi_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sapi/litespeed/lsapi_main.c b/sapi/litespeed/lsapi_main.c index 2b2385c..d

[PHP-DEV] [PATCH 1/3] Fix multiple pieces of code in lsapilib.c.

--- These issues are not serious(only triggerable by the runner/caller of the PHP program), so no need to make them private. sapi/litespeed/lsapilib.c | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/sapi/litespeed/lsapilib.c b/sapi/litespeed/lsapilib.c index

Re: [PHP-DEV] [PATCH] Fix uninitalized variables reads. See CWE-457 for more info.

On 21/01/15 07:28, Joshua Rogers wrote: > --- > ext/mbstring/mbstring.c | 8 > ext/reflection/php_reflection.c | 1 + > main/main.c | 1 + > 3 files changed, 6 insertions(+), 4 deletions(-) > > diff --git a/ext/mbstring/mbstring.c b/ext/mbstring/mbstring.c > in

[PHP-DEV] [PATCH] Fix uninitalized variables reads. See CWE-457 for more info.

--- ext/mbstring/mbstring.c | 8 ext/reflection/php_reflection.c | 1 + main/main.c | 1 + 3 files changed, 6 insertions(+), 4 deletions(-) diff --git a/ext/mbstring/mbstring.c b/ext/mbstring/mbstring.c index 7f2209f..504a5e6 100644 --- a/ext/mbstring/mbstring

Re: [PHP-DEV] [PATCH] Remove useless tests

On 21/01/15 05:32, Alexey Zakhlestin wrote: >> > On 20 Jan 2015, at 21:00, Joshua Rogers wrote: >> > >> > Respective variables are unsigned and cannot be <0. > Did you mean to use “==“ in comparisons? > > Yes. Fixed it in the pull request: https://github.com/MegaManSec/php-src/commit/eba0e0348e97

Re: [PHP-DEV] [PATCH] Remove useless tests

> On 20 Jan 2015, at 21:00, Joshua Rogers wrote: > > Respective variables are unsigned and cannot be <0. Did you mean to use “==“ in comparisons? > --- > sapi/litespeed/lsapilib.c | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/sapi/litespeed/lsapilib.c b/s

[PHP-DEV] [PATCH] Remove useless tests

Respective variables are unsigned and cannot be <0. --- sapi/litespeed/lsapilib.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/sapi/litespeed/lsapilib.c b/sapi/litespeed/lsapilib.c index 2e60701..20279d1 100644 --- a/sapi/litespeed/lsapilib.c +++ b/sapi/litespeed/

Re: [PHP-DEV] [PATCH] Fix potential int overflow in date extension.

On 20/01/15 06:15, Joshua Rogers wrote: > -- > ext/date/lib/tm2unixtime.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Somebody please take a look at /ext/date/lib/parse_tz.c too: 438timelib_sll timelib_get_current_offset(timelib_time *t) [..] 446return (t

[PHP-DEV] [PATCH] Fix potential int overflow in date extension.

--- ext/date/lib/tm2unixtime.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/ext/date/lib/tm2unixtime.c b/ext/date/lib/tm2unixtime.c index c058672..94e5254 100644 --- a/ext/date/lib/tm2unixtime.c +++ b/ext/date/lib/tm2unixtime.c @@ -334,9 +334,9 @@ static timelib_sll do

[PHP-DEV] [PATCH] Fix integer overflow in calender.

Fix in overflows in conversation functions for calendar. Add tests for the overflows. --- ext/calendar/calendar.c| 2 +- ext/calendar/gregor.c | 2 +- ext/calendar/julian.c | 2 +- ext/calendar/tests/gregoriantojd_overflo

Re: [PHP-DEV] [PATCH] Fix octal parsing (finally)

Hi! Since it’s been a week and there have been no objections, I’ve merged the octal fix patch into php master: https://github.com/php/php-src/commit/5f29b980514867f1a09969ca6a1c1f5fb00c3027 Finally, it is fixed after all these years :) -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP

[PHP-DEV] [PATCH] Fix bug #68711 Remove useless checks. 'num' is unsigned and cannot be <0.

--- ext/dba/libflatfile/flatfile.c | 28 1 file changed, 4 insertions(+), 24 deletions(-) diff --git a/ext/dba/libflatfile/flatfile.c b/ext/dba/libflatfile/flatfile.c index b5028f5..f640e19 100644 --- a/ext/dba/libflatfile/flatfile.c +++ b/ext/dba/libflatfile/flatfile

[PHP-DEV] [PATCH] Fix missing space in previous commit

--- main/spprintf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/main/spprintf.c b/main/spprintf.c index ba12868..5f50d8a 100644 --- a/main/spprintf.c +++ b/main/spprintf.c @@ -845,7 +845,7 @@ PHPAPI size_t vspprintf(char **pbuf, size_t max_len, const char *format, va_list

[PHP-DEV] [PATCH] Fix null pointer dereferences

-- Multiple places 'spprintf' is called with a NULL 'pbuf', which passes itself to vspprintf, which dereferences it. Although most places check whether 'pbuf'(normally called 'error') is null, it is smarter to check it inside the function that requires a non-null value. This will avoid future pr

Re: [PHP-DEV] [PATCH] Fix null pointer dereference(s) --

On 16/01/15 19:23, Stanislav Malyshev wrote: > No C++ comments please. Fixed.(Will push afterwards) >> >if (buf.c) { >> > - *pbuf = buf.c; >> > + if(pbuf) { >> > + *pbuf = buf.c; >> > + } >> >result = buf.len; > I think if pbuf is null, it

Re: [PHP-DEV] [PATCH] Fix null pointer dereference(s) --

Hi! > + //Test 'pbuf'(also known as 'error') against NULL, since it is called > multiple places without checking against, causing null pointer dereferences. No C++ comments please. > if (buf.c) { > - *pbuf = buf.c; > + if(pbuf) { > + *pbuf =

[PHP-DEV] [PATCH] Fix null pointer dereference(s) --

Multiple places 'spprintf' is called with a NULL 'pbuf', which passes itself to vspprintf, which dereferences it. Although most places check whether 'pbuf'(normally called 'error') is null, it is smarter to check it inside the function that requires a non-null value. This will avoid future proble

Re: [PHP-DEV] [PATCH] Fixed bug #68839 Possible null pointer dereference

On 16/01/15 03:48, Joshua Rogers wrote: > Should the patch, perhaps be inside the spprintf() function? > That would take care of future problems, too. > > Thoughts? Ok, so, there are many many places where 'error' is not checked against NULL. So I'm going to submit a patch that will fix this in th

Re: [PHP-DEV] [PATCH] Fixed bug #68839 Possible null pointer dereference

Hi, On 16/01/15 03:41, Michael Wallner wrote: > Looks good. There's another one(2) in /ext/phar/util.c: --snip-- 911if (error) { 912*error = NULL; 913} 914/* seek to start of internal file and read it */ 915if (FAILURE == phar_open_entry_fp(en

Re: [PHP-DEV] [PATCH] Fixed bug #68839 Possible null pointer dereference

On 15/01/15 17:31, Joshua Rogers wrote: > --- > ext/phar/zip.c | 12 +--- > 1 file changed, 9 insertions(+), 3 deletions(-) > > diff --git a/ext/phar/zip.c b/ext/phar/zip.c > index 2a95580..2117b0e 100644 > --- a/ext/phar/zip.c > +++ b/ext/phar/zip.c > @@ -1217,7 +1217,9 @@ int phar_zip_f

[PHP-DEV] [PATCH] Fixed bug #68839 Possible null pointer dereference

--- ext/phar/zip.c | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/ext/phar/zip.c b/ext/phar/zip.c index 2a95580..2117b0e 100644 --- a/ext/phar/zip.c +++ b/ext/phar/zip.c @@ -1217,7 +1217,9 @@ int phar_zip_flush(phar_archive_data *phar, char *user_stub, zend_long

Re: [PHP-DEV] [PATCH] Check the return value of do_fstat() to avoid error conditions.

Hi, On 15/01/15 21:49, Xinchen Hui wrote: >do you have a test script to show how to reproduce the error? > > thanks No, I don't. But, if you run `grep -nr do_fstat main/streams/plain_wrapper.c -C3', you can see the result is compared against '0' everywhere else it is used. Thanks, -- -- Josh

Re: [PHP-DEV] [PATCH] Check the return value of do_fstat() to avoid error conditions.

Hey: On Thu, Jan 15, 2015 at 4:02 PM, Joshua Rogers wrote: > --- > main/streams/plain_wrapper.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/main/streams/plain_wrapper.c b/main/streams/plain_wrapper.c > index f52383d..72be0b0 100644 > --- a/main/streams/plain_wrapp

[PHP-DEV] [PATCH] Check the return value of do_fstat() to avoid error conditions.

--- main/streams/plain_wrapper.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/main/streams/plain_wrapper.c b/main/streams/plain_wrapper.c index f52383d..72be0b0 100644 --- a/main/streams/plain_wrapper.c +++ b/main/streams/plain_wrapper.c @@ -669,7 +669,8 @@ static int php_

[PHP-DEV] [PATCH] Check the return value of do_fstat() to avoid error conditions.

From: Joshua Rogers --- main/streams/plain_wrapper.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/main/streams/plain_wrapper.c b/main/streams/plain_wrapper.c index f52383d..72be0b0 100644 --- a/main/streams/plain_wrapper.c +++ b/main/streams/plain_wrapper.c @@ -669,7 +66

Re: [PHP-DEV] [PATCH] Fix octal parsing (finally)

Hey: On Sun, Jan 11, 2015 at 6:37 AM, Andrea Faulds wrote: > Hey internals, > > A longstanding PHP bug is that invalid octal digits simply terminate the > literal and are ignored, rather than generating a compile error. Thus, this > is valid: > > $x = 0109; // same as 010, or 8 > > I see no

Re: [PHP-DEV] [PATCH] Fix octal parsing (finally)

Hi all, Nice fix, Andrea! On Sun, Jan 11, 2015 at 8:55 AM, Stanislav Malyshev wrote: > > A longstanding PHP bug is that invalid octal digits simply terminate > > the literal and are > ignored, rather than generating a compile error. Thus, this is valid: > > > > $x = 0109; // same as 010, or 8 >

Re: [PHP-DEV] [PATCH] Fix octal parsing (finally)

Hi! > A longstanding PHP bug is that invalid octal digits simply terminate > the literal and are ignored, rather than generating a compile error. Thus, this is valid: > > $x = 0109; // same as 010, or 8 > > I see no particular reason why this behaviour should be preserved. > I’ve written a patch

[PHP-DEV] [PATCH] Fix octal parsing (finally)

Hey internals, A longstanding PHP bug is that invalid octal digits simply terminate the literal and are ignored, rather than generating a compile error. Thus, this is valid: $x = 0109; // same as 010, or 8 I see no particular reason why this behaviour should be preserved. I’ve written a p

Re: [PHP-DEV] [PATCH] Consistent type names in error messages

Am 14.12.2014 um 19:35 schrieb Andrea Faulds: > Thoughts? +1 for consistency :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] Consistent type names in error messages

Hey Rowan, > On 14 Dec 2014, at 21:20, Rowan Collins wrote: > > I had a go at this a few months ago, but haven't updated my patch based on > what's changed in the engine since, so it probably wouldn't merge cleanly: > https://github.com/php/php-src/pull/769 Yeah, I was inspired by your effort

Re: [PHP-DEV] [PATCH] Consistent type names in error messages

On 14/12/2014 18:35, Andrea Faulds wrote: Good evening, Unfortunately, zend_parse_parameters and userland type hint error messages use outdated type names, and don’t even do so consistently. For example: $ php -r 'fread(0, 0);' PHP Warning: fread() expects parameter 1 to be resource, integer

Re: [PHP-DEV] [PATCH] Consistent type names in error messages

Hi Andrea 2014-12-14 21:01 GMT+01:00 Andrea Faulds : > It wouldn’t break anything, I say make a pull request. See: http://news.php.net/php.cvs/83688 http://news.php.net/php.doc.cvs/12965 -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List T

Re: [PHP-DEV] [PATCH] Consistent type names in error messages

> On 14 Dec 2014, at 19:59, Kalle Sommer Nielsen wrote: > > 2014-12-14 19:44 GMT+01:00 Andrea Faulds : >> Hi Kalle, > > Hi Andrea >> Also, a sidenote: In case someone goes and checks the manual and tells me >> that is_long() is already an alias of is_int() and not the other way around, >> the

Re: [PHP-DEV] [PATCH] Consistent type names in error messages

2014-12-14 19:44 GMT+01:00 Andrea Faulds : > Hi Kalle, Hi Andrea > Also, a sidenote: In case someone goes and checks the manual and tells me > that is_long() is already an alias of is_int() and not the other way around, > the manual lies. In fact, is_int() is currently an alias of is_long() in

Re: [PHP-DEV] [PATCH] Consistent type names in error messages

Hi Kalle, > On 14 Dec 2014, at 18:41, Kalle Sommer Nielsen wrote: > > 2014-12-14 19:35 GMT+01:00 Andrea Faulds : >> >> I want to change the type names to be consistent, because I think our >> current inconsistency is confusing. Integers are sometimes ints or integers, >> but other times longs

Re: [PHP-DEV] [PATCH] Consistent type names in error messages

2014-12-14 19:35 GMT+01:00 Andrea Faulds : > Good evening, > > Unfortunately, zend_parse_parameters and userland type hint error messages > use outdated type names, and don’t even do so consistently. For example: > > $ php -r 'fread(0, 0);' > PHP Warning: fread() expects parameter 1 to be resourc

[PHP-DEV] [PATCH] Consistent type names in error messages

Good evening, Unfortunately, zend_parse_parameters and userland type hint error messages use outdated type names, and don’t even do so consistently. For example: $ php -r 'fread(0, 0);' PHP Warning: fread() expects parameter 1 to be resource, integer given in Command line code on line 1 $ php

[PHP-DEV] [PATCH] Make *nix build system more similar to Windows

Currently under *nix, the build system uses a hardcoded location where the extension is: /ext/ext-name. Windows is just looking at where the the current config.w32 file is, takes the directory it is in and handles it like the root of the extension. Just simple, no hardcoded paths, just dependin

Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql

On 03/11/2014 12:55, Matteo Beccati wrote: > [re: PQexec] Going from memory it is also used with > PGSQL_DISABLE_PREPARES (5.6+) if there are no bound parameters. Actually, that was true only in the earlier versions of the feature. I've decided not to do that to avoid behaviour changes and unplea

Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql

On 03/11/2014 12:40, Rowan Collins wrote: > When using a one-shot call to query() with multiple statements (e.g. > create temp table; populate temp table; select results) it's actually > necessary with Postgres to switch on emulation, and for that > emulation to allow multiple queries even though t

Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql

On 3 November 2014 09:18:08 GMT, Matteo Beccati wrote: >Hi all > >Resuming this once again after Anthony's blog post... > >On 16/10/2014 18:10, Ferenc Kovacs wrote: >> On Thu, Oct 16, 2014 at 5:47 PM, Rasmus Lerdorf >wrote: >>> I do agree that the default should probably be server-side since it >

Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql

Hi all Resuming this once again after Anthony's blog post... On 16/10/2014 18:10, Ferenc Kovacs wrote: > On Thu, Oct 16, 2014 at 5:47 PM, Rasmus Lerdorf wrote: >> I do agree that the default should probably be server-side since it is >> the least surprising. We just need to make it very very cle

Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql

Am 17.10.2014 um 15:09 schrieb Lester Caine: > On 17/10/14 13:20, Ulf Wendel wrote: >>> users know what they are getting and where the real security holes are. >> Hmm, maybe, you could make this world a better one by contributing to >> improve http://php.net/manual/en/pdo.prepared-statements.php ?

Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql

On 17/10/14 13:20, Ulf Wendel wrote: >> users know what they are getting and where the real security holes are. > Hmm, maybe, you could make this world a better one by contributing to > improve http://php.net/manual/en/pdo.prepared-statements.php ? PDO does not support management of SQL difference

Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql

Am 17.10.2014 um 13:47 schrieb Lester Caine: > users know what they are getting and where the real security holes are. Hmm, maybe, you could make this world a better one by contributing to improve http://php.net/manual/en/pdo.prepared-statements.php ? For the rest: the MySQL manual and the MySQL

Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql

On 17/10/14 11:17, Ulf Wendel wrote: > Am 17.10.2014 um 11:51 schrieb Lester Caine: >> On 16/10/14 18:59, christopher jones wrote: > >> Ulf stated early on in this thread re MySQL >>> - statement and parameter are send to the server independently >>> - the server builds the final statement strin

Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql

Am 17.10.2014 um 11:51 schrieb Lester Caine: > On 16/10/14 18:59, christopher jones wrote: > Ulf stated early on in this thread re MySQL >> - statement and parameter are send to the server independently >> - the server builds the final statement string > > Is this ACTUALLY how it works? Since

Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql

On 16/10/14 18:59, christopher jones wrote: > > The MySQL team has been improving their server-side prepare code: > http://mysqlserverteam.com/re-factoring-some-internals-of-prepared-statements-in-5-7/ It may be worth clarifying some terms here since people are talking about restrictions that MyS

Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql

2014.10.17. 6:51 ezt írta ("Rasmus Lerdorf" ): > > On 10/16/2014 09:10 AM, Ferenc Kovacs wrote: > > I don't think we should remove the option, just change the defaults, and > > most people would be fine switching back to the emulation, but it should > > be their conscious decision imo. > > Currentl

Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql

On 10/16/2014 09:10 AM, Ferenc Kovacs wrote: > I don't think we should remove the option, just change the defaults, and > most people would be fine switching back to the emulation, but it should > be their conscious decision imo. > Currently many people aren't aware that they are using client side

Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql

On 10/16/2014 02:38 PM, Morgan Tocker wrote: > The more clear cases would be: > - The prepared statement is reused enough times that the initial extra round > trip can be amortized. > - If large place-holder values can be sent direct to the server without > having to be escaped or parsed. For e

Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql

On 16 October 2014 18:39:57 GMT+01:00, Olivier Bonvalet wrote: >Le jeudi 16 octobre 2014 à 18:10 +0200, Ferenc Kovacs a écrit : >> On Thu, Oct 16, 2014 at 5:47 PM, Rasmus Lerdorf >wrote: >> >> > On 10/16/2014 04:27 AM, Ferenc Kovacs wrote: >> > > On Fri, Jun 15, 2012 at 3:01 AM, Anthony Ferrara

Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql

On 10/16/14, 8:47 AM, Rasmus Lerdorf wrote: On 10/16/2014 04:27 AM, Ferenc Kovacs wrote: On Fri, Jun 15, 2012 at 3:01 AM, Anthony Ferrara wrote: Hello all, I raised this topic on list over a year ago ( http://marc.info/?l=php-internals&m=130417646507744&w=2 ). It was determined that it was

Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql

Le jeudi 16 octobre 2014 à 18:10 +0200, Ferenc Kovacs a écrit : > On Thu, Oct 16, 2014 at 5:47 PM, Rasmus Lerdorf wrote: > > > On 10/16/2014 04:27 AM, Ferenc Kovacs wrote: > > > On Fri, Jun 15, 2012 at 3:01 AM, Anthony Ferrara > > > wrote: > > > > > >> Hello all, > > >> > > >> I raised this topi

Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql

On Thu, Oct 16, 2014 at 5:47 PM, Rasmus Lerdorf wrote: > On 10/16/2014 04:27 AM, Ferenc Kovacs wrote: > > On Fri, Jun 15, 2012 at 3:01 AM, Anthony Ferrara > > wrote: > > > >> Hello all, > >> > >> I raised this topic on list over a year ago ( > >> http://marc.info/?l=php-internals&m=1304176465077

Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql

On 10/16/2014 04:27 AM, Ferenc Kovacs wrote: > On Fri, Jun 15, 2012 at 3:01 AM, Anthony Ferrara > wrote: > >> Hello all, >> >> I raised this topic on list over a year ago ( >> http://marc.info/?l=php-internals&m=130417646507744&w=2 ). It was >> determined that it wasn't time yet to disable prepar

Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql

On Fri, Jun 15, 2012 at 3:01 AM, Anthony Ferrara wrote: > Hello all, > > I raised this topic on list over a year ago ( > http://marc.info/?l=php-internals&m=130417646507744&w=2 ). It was > determined that it wasn't time yet to disable prepared statement > emulation for MySQL yet. However, Rasmus

[PHP-DEV] [PATCH] Microsecond resolution and accuracy on Windows

Hi all! I'm back after several years, and will have a few more changes for Windows, at least. (It was CVS back then, so I still have to figure some things out... Just had to edit files on Github site. :-/) Anyway, this patch is for microtime, etc. on Windows XP-7. In March 2013, the fix f

Re: [PHP-DEV] [PATCH] Fixes for bugs #65463, #66036

On 08/14/2014 01:43 PM, Keyur Govande wrote: > Hello, > > I've opened https://github.com/php/php-src/pull/770 for patches for bugs > #65463, #66036. More details in the PR. > > The bug is reproducible on PHP 5.4, 5.5 and 5.6 with and without > --enable-zend-signals. > > Please review, I'm hesita

  1   2   3   4   5   6   7   8   9   10   >