On Tue Jul 31 12:21 PM, Anthony Ferrara wrote:
> Jonathan,
>
>
> Again, implementing something in the core that's not verified and
> can't be implemented well by the vast majority of developers out
> there.
Alright so I found some people supporting my claims:
http://blog.mozilla.org/webappsec
>
> Also, be aware that BCrypt only uses the first 72 characters of the
> password field. So if you use a hex encoded sha512 output, a good deal
> of entropy would be lost (almost half of it)...
>
Good to know, do most hash algorithms have limitations on the # of chars as
input?
That would ex
On Tue Jul 31 10:54 AM, Anthony Ferrara wrote:
>
> On Tue, Jul 31, 2012 at 10:28 AM, Jonathan Bond-Caron
> I strongly disagree with this, the 'pepper' IMHO is a best practice
> for web applications.
>
> Again, I have not seen this being said by any security or cryp
>
> RFC:
> https://wiki.php.net/rfc/password_hash#the_api_does_not_support_pepper
>
Thanks, I missed it...
I strongly disagree with this, the 'pepper' IMHO is a best practice for web
applications.
I prefer to live with the idea that an attacker may comprise some
database(s) in the 'cloud' bu
> Say you have:
> define('MY_HASHING_SECRET', 'hhtrg54~%$%4long'); $password =
> '1234';
>
> password_hash_rfc($password . MY_HASHING_SECRET,
> PASSWORD_METHOD_BCRYPT); password_hash($password, MY_HASHING_SECRET);
>
> Note here that in both cases we let crypt() generate a random salt that
>
On Thu Jul 12 02:34 PM, Anthony Ferrara wrote:
>
> > https://wiki.php.net/rfc/password_hash
-- password_hash()
password_hash_rfc(string $password, int $algo, array $options = array())
My personal opinion is the api should be:
password_hash(string $password, string $secret = '', array $options
On Wed Jun 27 12:32 PM, Arvids Godjuks wrote:
> because at the moment i do not understand how salt stored in the hash itself
> makes hash more
> secure than an unsalted one.
a) In terms of 'effort' to break many passwords, there's a benefit to the salt
stored in the hash itself.
It's not 'more
On Mon Jun 18 07:14 PM, Anthony Ferrara wrote:
>
> https://wiki.php.net/rfc/hash_pbkdf2
>
I like this proposal, it could be useful to add a simpler api that has
defaults matching the NIST recommendation:
hash_password($password, $salt, $algo = 'sha1', $iterations = 1000);
if the salt doesn't h
On Fri Nov 11 12:13 AM, Stas Malyshev wrote:
>
> > - MODE_DEBUG: This one can work together with the other two,
> > allowing a validation of class/interface/trait presence in the file.
> Basically,
> > it requires the file and then checks if the item exists in scope.
>
> Not sure debug adds much
On Wed Nov 9 10:01 PM, guilhermebla...@gmail.com wrote:
>
> Some would simply say "he only did that because he got 3 proposals
> rejected". Others would say "he is pressuring A to be in PHP". But not.
> I learned the hard way and multiple times to hear a big NO. But at the
> same time, I earn my
Bring improvements to serialize() and unserialize() -- a consistent
serialize_text() which does change based on config + no more NULL bytes.
Possible improvements to PDO and stream related enhancements.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.p
On Sat Oct 22 04:38 AM, Nathan Nobbe wrote:
> Hi folks,
>
> With a 5.4 release right around the corner I'd like a moment of your
> time to reconsider this issue [1].
>
> Just curious why it died on the table if several folks saw value in
> it, including Stephan who I gather is the primary archit
On Thu Nov 3 03:06 PM, Will Fitch wrote:
> Wouldn't you consider spl_autoload_register an interoperability
> solution? Only your defined autoloading function would then need to
> know how your file system is structured, there'd be no need for
> include_path declarations and you wouldn't have to
On Thu Nov 3 11:19 AM, Anthony Ferrara wrote:
>
> But that's besides the point. I just want to emphasize the point that
> performance should not be a criteria for justifying it going into the
> core...
>
There also seems to be the perception among some php devs that autoloading
is now the pre
On Sat Oct 22 10:25 AM, Anthony Ferrara wrote:
> Well, I have a few opinions on this that I think are worth sharing:
>
> 1. If this change is made, we no longer would have mixins, but would
> have regular multiple-inheritance (With all the "issues" associated
> with it). Note that I said mixins
On Sun Oct 16 06:59 PM, Stas Malyshev wrote:
> It definitely makes PHP worse by propagating inconsistent APIs.
I created a patch against 5.4:
https://bugs.php.net/patch-display.php?bug_id=55475&patch=is_a_5.4_alternati
ve&revision=latest
The patch changes the behavior to:
is_a("ab", "b") // false
On Wed Sep 21 09:57 AM, Matthew Weier O'Phinney wrote:
>
> > It then reverts is_a() back to the previous behavior, and clarifies
> > the documentation.
>
>
> To respect the release RFC, we shouldn't introduce a new BC break
> (breaking behavior with something already released).
>
That's just
On Wed Aug 24 08:42 AM, Pierre Joye wrote:
> Hi Alan,
>
> the breakage is about is_a with a string as 1st argument, not is_a as
> a whole. So yes, it breaks is_a alone is used as validation.
>
I've been digging more into this:
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/Zend/zend_bui
On Fri Aug 19 03:48 AM, Kingsquare.nl - Robin Speekenbrink wrote:
>
> Also the proposed include it -> read the data -> convert on write if
> in previous format (possibly an ini setting?) would provide full BC
> and would allow a painless upgrade... wouldnt it?
>
100% against enabling it by def
On Thu Aug 4 09:54 PM, Raymond Irving wrote:
> Hello,
>
> I came across this little library called TameJS (http://tamejs.org/)
> and fell in love with the it's syntax. This had me thinking if it was
> possible to add such features to a PHP CLI (or web app):
>
Thanks for sharing, never heard of
On Wed Aug 3 05:16 PM, Lester Caine wrote:
> Jan Dolecek wrote:
> > I was waiting for this for a while! I wrote a blog post how to get
> > best benefits from weak references:
> > http://blog.juzna.cz/2011/08/weak-references-in-php/
> > Perhaps this will help showing people what are they good for.
On Fri Jul 22 01:46 PM, Alex Howansky wrote:
>
> Sure, but in this case, I created the conflict intentionally because I
> *want* to override it, and I'm not allowed to like I am with methods.
> Don't you think that's inconsistent?
>
Agree
> > The short answer is it's not a bug but maybe an imp
On Fri Jul 22 11:17 AM, Alex Howansky wrote:
> trait foo
> {
> public $zoo = 'foo::zoo';
> public function bar()
> {
> echo "in foo::bar\n";
> }
> }
>
> class baz
> {
> use foo;
> public $zoo = 'baz::zoo';
> public function bar()
> {
>
On Wed Jun 22 11:25 AM, Reindl Harald wrote:
>
> and php as primary web-language is missing UTF8 support in the core
You have a valid point.
Now onto "foreach() for strings", any other opinions?
Seems like the discussion is closed and most likely should move to a RFC
with some consideration ab
On Mon Jun 20 09:11 AM, Lee davis wrote:
>
> Could we also use current(), next() and key() for iteration of strings?
>
> $string = 'string';
> while ($char = current($string))
> {
> echo key($string) // Would output the offset position I assume 0,1,2
> etc??
> echo $char // outputs eac
On Mon May 9 07:29 PM, guilhermebla...@gmail.com wrote:
> Hi Andi,
>
> Sorry, but I mentioned on other thread that RFC is outdated.
> I just finished an update to it bringing to recent implementation. The
> idea is to get the "big picture" here, I may have left from previous
> RFC, but if I did
On Tue May 10 11:07 AM, guilhermebla...@gmail.com wrote:
>
>
> I'm not putting traits support inclusion on risk. I'm a string +1 to
> it.
> All I want is that you stop giving stupid arguments to be against the
> patch instead of giving *real* relevant arguments.
>
Complexity:
http://en.wikipe
On Wed Apr 20 04:41 PM, D. Dante Lorenso wrote:
>
> My proposal was called "filled" since it was the opposite of "empty"
> which already existed. I extended the function to return the first
> non-empty value or null if all values evaluated as empty.
>
> You could use the function like this:
>
On Wed Apr 20 10:55 AM, Mark wrote:
>
> function varset($arr, $key, $default = '') { return (isset($arr[$key])
> ? $arr[$key] : $default); }
>
> where the call would be:
> $var = varset($_GET, 'var');
>
> I personally like both ways...
> My proposal is to make this function a core php function
On Wed Mar 30 09:05 AM, Hannes Landeholm wrote:
>
> var_dump(\substr("foo", 5, 6) == "", (string) false, false == "");
>
> Welcome to PHP. To be honest this criticism pretty much falls in the
> "from person that comes from another language X and is annoyed that
> every little detail isn't exact
On Thu Feb 10 12:25 PM, Ben Schmidt wrote:
>
> http://wiki.php.net/rfc/traitsmodifications
>
Some thoughts:
a) Class method conflict with trait
Class implementation always wins I feel is the right way to think about
traits.
But 'abstract' already has special meaning, so maybe a keyword like '
On Sun Feb 13 05:15 AM, André Rømcke wrote:
> >
> > I have now made an RFC based on the most recent discussions:
> >
> > http://wiki.php.net/rfc/traitsmodifications
> >
>
> I think it would sometimes be desirable to allow this, for instance
> when a trait has been updated in a framework to adapt
On Sat Jan 8 06:33 AM, Ben Schmidt wrote:
>
> > Creating a patch will help getting feedback about what you're
> > proposing http://ca3.php.net/reST/php-src/README.MAILINGLIST_RULES
>
> I hope I haven't broken any of the mailing list rules, but my
> apologies if I have, and please point out spec
On Sun Jan 2 07:16 AM, Ben Schmidt wrote:
> I would also like to propose some extensions to the functionality as
> currently described, which I think could potentially add tremendous
> power to the mechanism, with relatively little additional conceptual
> complexity and implementation effort. I'
On Mon Dec 20 06:21 PM, Stefan Marr wrote:
>
> = Handling of Properties/State =
>
> This property handling was implemented in
> [[http://svn.php.net/viewvc?view=revision&revision=306476|SVN revision
> 306476]] and examples are given in the test cases.
>
+1
The E_STRICT warning seem
On Sat Dec 18 12:33 PM, Stefan Marr wrote:
> Hi Jonathan:
>
> On 18 Dec 2010, at 18:14, Jonathan Bond-Caron wrote:
>
> > Does the order of the declaration matter?
> No, the order does not matter, and that is one of the key points of
> traits compared to mixins or
On Sat Dec 18 10:29 AM, Stefan Marr wrote:
> At least I do not find an argument for either way that completely
> convinces me.
> At the moment, the main reason is that 'public' can be considered to
> be the default visibility modifier.
> Based on the semantics of 'var' and dynamic properties.
> T
On Sun Dec 12 04:33 PM, Nathan Nobbe wrote:
>
>
> So the 'with/within' tokens would apply to traits.
>
> I feel 'expect', 'need', 'require' etc sound better, matter of opinion
> really, but it sounds like from an internals perspective it's
> preferred to reuse existing keywords if possible.
>
On Sat Dec 11 10:25 AM, Stefan Marr wrote:
>
http://wiki.php.net/rfc/horizontalreuse#requiring_composing_class_to_impleme
nt_interface
>
>
> Are there any objections to implementing this?
>
It's not a bad idea, though I haven't found a strong need for it in the way
I plan to use traits.
It als
On Sun Dec 5 12:44 PM, Benjamin Eberlei wrote:
>
> 1. Just create a DateTimeValue object that is immutable, not
> optimizing PHP to handle it with efficient garbage collection.
> 2. One step further, add a "static class DateTimeValue" like syntax
> that creates an immutable class.
>
> Any ideas
On Tue Nov 30 03:26 AM, Julien Pauli wrote:
> I guess serialize mechanism cant use any char that can be part of a
> PHP variable. And "_" can. As property names respect binary
> compatibility, the only char that can be used to mark private
> properties is actually the NULL byte. Ping me if I'm w
On Thu Dec 2 02:11 AM, Larry Garfield wrote:
>
> See, here's the fundamental problem we're running into. There's three
> different definitions of what a property is that we keep bouncing
> between, each of which will dictate both syntax and semantics:
>
> 1) Properties are a smart masking laye
On Mon Nov 29 09:27 AM, Stas Malyshev wrote:
> Hi!
>
> > Nice RFC, just an idea for an alternative syntax (added to the RFC
> > as
> #2):
> >
> > property Hours {
> > get { return $this->seconds / 3600; }
> > set { $this->seconds = $value * 3600; } // The variable $value
> holds
> > the i
On Sun Nov 28 06:18 PM, presid...@basnetworks.net wrote:
>
> Link to the RFC:
> http://wiki.php.net/rfc/propertygetsetsyntax
>
Nice RFC, just an idea for an alternative syntax (added to the RFC as #2):
property Hours {
get { return $this->seconds / 3600; }
set { $this->seconds =
On Thu Nov 25 12:47 PM, Andi Gutmans wrote:
>
> I know there have been some high-end apps that have benefited from
> some custom serializers, etc... (typically platform dependent).
> I wonder if people here think improvements in these areas would move
> the needle for the majority of mainstream
On Thu Nov 18 08:34 AM, guilhermebla...@gmail.com wrote:
> Hi Larry,
>
> For existent project examples and usage, here are 2 links of the
> upcoming versions of Doctrine 2 and Symfony 2:
>
> http://www.doctrine-project.org/projects/orm/2.0/docs/reference/basic-
> mapping/en#introduction-to-docbl
On Fri Nov 5 12:57 AM, Stanley Sufficool wrote:
> >
> > And why is PHP client library using latin1 for data that just isn't
> > latin1? That's just asking for problems...
>
> Theoretically I could ask for UTF8, but then I don't want to have to
> run utf8_decode/utf8_encode on all query strings,
On Fri Sep 17 03:13 PM, Ralph Schindler wrote:
> Inline response:
>
> On 9/17/10 1:57 PM, Jonathan Bond-Caron wrote:
> > On Fri Sep 17 01:06 PM, Guilherme Blanco wrote:
> >>
> >> Another good example is to map your persistence data into your
> >> Entiti
On Fri Sep 17 01:06 PM, Guilherme Blanco wrote:
>
> Another good example is to map your persistence data into your
> Entities. Doctrine 2 implements this and I think that way you can
> compare easily with the PHP code alternative. I'd like to ask you to
> compate the same Entity mapped through
On Thu Sep 16 02:44 PM, Stas Malyshev wrote:
>
> WTF is "Annotations"? We didn't define it yet. Should PHP support
http://en.wikipedia.org/wiki/.NET_metadata
http://blogs.msdn.com/b/efdesign/archive/2010/03/30/data-annotations-in-the-entity-framework-and-code-first.aspx
.NET calls this attribut
-1 for the proposed Annotations concept and associated syntax
+1 for adding APIs to parse doc blocks, minor note: should not be not called
"getAnnotations"
On Thu Sep 16 01:01 PM, Lars Schultz wrote:
> +1 for adding APIs to parse doc blocks
> -1 for introducing a new Annotations concept and assoc
On Wed Sep 15 12:17 PM, Guilherme Blanco wrote:
> I think meta programming is not and would never be part of comment.
> As previously said, docblock means documentation, without any meaning
> to parser, entirely human readable and totally removable without
> affecting overall execution.
I have t
On Tue Sep 14 01:25 PM, Nate Abele wrote:
>
> Sorry, but I don't see how this is even remotely close to being
> appropriate for PHP. Maybe I'm missing something. :-)
>
I agree, the use cases are just not there
Though maybe some form of "annotations" could be useful in php as a
"pluggable type"
On Fri Aug 20 09:10 AM, Jonathan Bond-Caron wrote:
>
> Maybe Stas can comment but I can't reproduce the E_STRICT warning Is
> this php HEAD?
>
> class ObjParent {
> function set($param2 = '') {}
> }
>
> class ObjChild extends Ob
On Fri Aug 20 08:24 AM, Nathan Rixham wrote:
> Jonathan Bond-Caron wrote:
> > On Fri Aug 20 06:54 AM, Jean-Sébastien H. wrote:
> >> No it's wrong.
> >>
> >> A Child is a Parent so we must be able to pass a Parent to the
> method
> >> equals
On Fri Aug 20 06:54 AM, Jean-Sébastien H. wrote:
> No it's wrong.
>
> A Child is a Parent so we must be able to pass a Parent to the method
> equals() defined on Child.
>
> The declaration of the parent functions must always be valid in the
> children.
>
Maybe my OO theory is wrong but I was
On Tue Aug 10 07:42 PM, Josh Davis wrote:
> Derick's point was about consistency. The approach described in his
> mail is consistent with current syntax and mechanism(s). Current
> typehints do not apply any kind of conversion, so treating scalar
> hints the same way is consistent with the curre
I've starting playing around with the zend engine,
is there any hope / plans for better interoperability with how
zend_compile_file() should be extended?
The goal being to reduce the amount of "X is not compatible with Y".
It would be possible to separate extensions in two categories and
On Wed Jun 16 07:04 AM, Ilia Alshanetsky wrote:
> > > drop the Sqlite2 extensions from Trunk as they are superseded by
> the
> > Sqlite3
> > > extensions. The sqlite2 library is no longer maintainer and the
> > > migration path from version 2 to 3 is very simple. Unless there
> > > any objections
On Thu May 27 11:22 AM, David Soria Parra wrote:
> On 2010-05-27, Zeev Suraski wrote:
> +1 from me for this. I think two solutions is not the right way and we
> +should
> try to make the type system consistent for the user. Therefore +1 for
> auto-converting.
I still feel the debate of the "rig
On Mon Apr 12 05:16 AM, Stefan Marr wrote:
>
> On 12 Apr 2010, at 10:39, Lukas Kahwe Smith wrote:
> > On 12.04.2010, at 10:34, Derick Rethans wrote:
> >> Hi!
> >>
> But just as a quick response, without aliasing, there would be no way
> to use a conflicting method from a trait.
> On first sight,
On Wed Mar 24 06:50 AM, Lukas Kahwe Smith wrote:
> The third sentence is not so clear to me, but if I guess it its also
> just a typo as it makes more sense to me when replacing "renaming" to
> "result in renaming". But maybe you could tweak that paragraph to be a
> bit clearer. For example its
On Wed Mar 24 06:50 AM, Lukas Kahwe Smith wrote:
> Ahoi,
>
> Thought it would be better to open up a new thread and also using the
> term "horizontal reuse" in the subject so that we make it clearer that
> there are actually two approaches. Here is the URL for Stefan's
> proposal:
> http://wiki.
On Wed Oct 14 04:07 PM, Lukas Kahwe Smith wrote:
>
> On 14.10.2009, at 22:03, Stanislav Malyshev wrote:
>
> > Hi!
> >
> >>> So lets warm this up again.
> >>> HEAD is for development .. so lets get this into HEAD so that it
> >>> will be part of the next bigger PHP release for sure!
> >> Well, th
On Thu Jul 2 08:53 AM, Paul Biggar wrote:
> On Thu, Jul 2, 2009 at 1:43 PM, Ilia Alshanetsky wrote:
> >
> > On 2-Jul-09, at 4:45 AM, Paul Biggar wrote:
> >> I think you might not have read what I suggested (it is different
> >> than the one I emailed to you privately). What you want is fully
> sup
On Mon Mar 2 11:10 PM, Andi Gutmans wrote:
> I don't see a fundamental issue why it could not be arbitrary.
> The only challenge which may be an issue is that this code clearly
> allocates the buffer on the stack for what are probably performance
> reasons. If you allow arbitrary chunk size and u
Hi everyone, I have a question about streams and the maximum chunk size of
8192.
Ive read README.STREAMS and found these slides by Wez:
http://netevil.org/blog/2008/07/slides-php-streams
While trying to write an Amazon S3 stream wrapper and I ran into an issue
with large files:
$f
On Sat Dec 6 12:09 AM, Lester Caine wrote:
> Derick Rethans wrote:
> >> ( Slipping a date through DateTime and returning it DATE_W3C seems
> to
> >> be adding the correct daylight saving details so far and allowing
> >> ADOdb date to work )
> >
> > This is not the correct thing to do, as you will
On Wed Nov 12 02:14 PM, Lukas Kahwe Smith wrote:
> 1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC
> I) enable ext/hash by default
+1
> II) remove ext/mhash
0
> 2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/
+1
> 3) resource constants (choose one
Hi Everyone,
I've started a new RFC about PHP and mixins:
http://wiki.php.net/rfc/mixin
Stefan has done some really interesting research with traits though I'm
concerned about how intuitive it is.
Good summary of how mixins and traits deal with conflict here:
http://marc.info/?l=php-
On Thu Aug 28 01:47 PM, Christian Seiler wrote:
> Hi again,
>
>> A few weeks ago I wrote quite a long posting to internals@ that tried
>> to clarify the situation on the round() function in PHP. I was asked
>> to write it up as an RFC in the wiki, which I have done:
>>
>> http://wiki.php.net/rf
On Mon Aug 25 06:28 PM, steve wrote:
> Has anyone had success compiling PHP with LLVM?
>
I haven't tried it, here is a good summary:
http://llvm.org/devmtg/2008-08/Lopes_PHP-JIT-InTwoDays.pdf
In short, it is 'slower' but that seems to be without any caching of the
"bytecode"
Bytecode is not opc
It's a big +1 for me and this sums it up
> PHP is about building on the knowledge and experience of the typical
> target user. This target user changes slowly as we all get older and
> the industry we are in changes and we need to recognize that and adapt
> the language appropriately. What is
+1 here
A summary:
PHP6 MUST not allow setting magic quotes
PHP6 MUST trigger a fatal error when attempting to set magic quotes (php.ini
or set_magic_quotes_runtime())
PHP6 MUST allow getting magic quotes info (always false)
PHP5.3 MUST allow setting magic quotes
PHP5.3 MUST trigger an E_DEPREC
xpected: 0,3
echo "\n";
echo sprintf('%G', 0.3);// 0,3
// expected: 0,3
echo "\n";
I'll dig more into the code... just thought I would share this (PHP 5.2.3)
-Original Message-
From: Stefan Walk [mai
rk as the
> average person would expect. Unfortunately, that would be a huge
> BC break. However, perhaps the perfect shouldn't be the enemy of
> the good and we shouldn't let the inability to fix floats as
> array indices be a reason not to improve "==".
> - T
on't know the float-to-string internals but it seems to do 'right' thing.
We get '1960', then converting back to a float, all accuracy bits are 0, so
(numeric)$test == (double)1960
I would guess adding a new type is a big amount work?
-Original Message-
From: P
Hi,
I'm new to the PHP internals list and I'm posting an issue I'm sure has been
mentioned before -- float comparison
I'd like to know if there are reasons not to change the default behavior
when comparing floats.
i.e. This would seem logical to me:
$test = 19.6*100;
78 matches
Mail list logo
