PDO ODBC #42765 uninitialized length bug patch
https://bugs.php.net/bug.php?id=42765
Any takers? Would we be able to get this patch committed? It's a
pretty straight forward fix.
Thanks,
--
Anish
On 11/02/2016 10:32, Anish Mistry wrote:
> Would a developer be able look at the patch in this
Hi,
The codes that show usage of smart_string:
- smart_str str = {0};
- smart_str_appendl(str, " ", sizeof(" ") - 1);
- smart_str_0(str);
- RETURN_STRINGL(implstr.c, implstr.len, 0);
+ smart_string str = {0};
+ smart_string_appendl(str, " ", sizeof(" ") - 1);
+ smart_string_0(str);
+
On 17/6/17 5:53 pm, Fleshgrinder wrote:
Hi!
I started voting on the Doxygen RFC:
https://wiki.php.net/rfc/doxygen
Did I miss seeing when the vote ends?
Chris
--
http://twitter.com/ghrd
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Results for project PHP master, build date 2017-06-20 08:30:24-07:00
commit: c18ba68
previous commit:e0403eb
revision date: 2017-06-20 10:11:41-04:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
Hi!
> From the history it looks like you didn't push the 7.0 branch.
>
> See also the commit mail which only references 7.1 and master.
> http://news.php.net/php.cvs/96748
Ok, I've re-added them to 7.0 and pushed it. Anatol, could you also add
these to the release branch so that 7.0 would be
On 19 June 2017 21:22:53 BST, Rasmus Schultz wrote:
>So what's on the table is a syntax-improved but feature-crippled
>variant of
>closures, not an all-round replacement?
I haven't the time right now to dig out my summary from the mail archives, but
this is one of the
Hi,
Le 20/06/2017 à 18:35, 江湖大虾仁 a écrit :
Hi François,
Good work, but I'm not sure if I missed something because I didn't
find any discuss relating to this RFC in my mail box, as well as the
PR on GitHub. I have a question about the detail of `cache_key`:
Discussion :
> I just think your example is an exaggeration to what happens in practice.
I think it's an example of what happens with any inconsistent feature in
any language.
On Tue, Jun 20, 2017 at 9:53 AM, Markus Fischer wrote:
> Hello Rasmus,
>
> On 19.06.17 22:22, Rasmus Schultz
Hi François,
Good work, but I'm not sure if I missed something because I didn't find any
discuss relating to this RFC in my mail box, as well as the PR on GitHub. I
have a question about the detail of `cache_key`:
> If the method is not defined, every path associated to this wrapper are
>
Well, the Ruby/Rust syntax would serve us well here too:
$things->forEach(|$v| {
foo($v);
bar($v);
});
On 19 Jun, 2017, at 09:43 PM, Rasmus Schultz wrote:
I actually like this syntax, but what would it look like for multi-statement
closures?
A nested set of curly
On Mo, 2017-06-19 at 17:58 -0700, Stanislav Malyshev wrote:
> Hi!
>
> I've discovered something weird in 7.0 branch. There are two commits
> of
> a bugfix -
> https://github.com/php/php-src/commit/d1d002fc4dd25a80e20163b18880f40
> a445276e7
> and
>
I'll double check later today, it might be that this comes in from the
startup phase and we can't do zend_error() for some reason. Either
way I'll get it merged soonish.
Thanks.
-Sara
On Tue, Jun 20, 2017 at 6:53 AM, François Laupretre
wrote:
> Hi Sara,
>
> Le 19/06/2017 à
Hi Sara,
Le 19/06/2017 à 23:33, Sara Golemon a écrit :
I was about to merge this, but ran into some issues (mostly minor).
Could you at least address the fwrite(stderr, ...) item (and
preferably clean up the style nits while you're at it)?
Oh, and I forgot to include it in the CR, but there
Hello Rasmus,
On 19.06.17 22:22, Rasmus Schultz wrote:
If I have to factor back and forth between new and old syntax every time a
closure changes from one to multiple or back to one statement, then,
frankly, what's the point?
I think I would just keep using the old syntax, then - for
14 matches
Mail list logo