Hi!
> Well, how about renaming the functions, create aliases for BC and throw
> E_DEPRECATED or E_STRICT on their usage? And write a PEAR script bundled
> with the distribution to migrate to the new convention?
Well, the problem with these things is this: suppose you have testing
suite that verif
Hi!
> Realistically couldn't we just introduce a configuration parameter to
> keep "the inconsistent parameter order," perhaps along with a script to
> suggest the changes needed to bring some code up to speed?
People think that "introduce a configuration parameter" is a solution to
almost any
Hi!
> I agree all of that would suck, but would it suck less than the
> alternatives for the most people involved?
Definitely not. I don't think most people involved care if it's called
htmlentities or html_entities. Those are things that you learn once and
don't care about them anymore, and if
Hi!
> So function aliases, new open tag and deprecation are bad. What about
> the String class?
Design it, write it and we'll see how it works. It's not like the
process should *start* with including it in PHP core. You can write
String class all by yourself, put it on github and once virtually
e
Hi!
> some time ago I created a small patch to make it possible to specify
> the temp dir by the php.ini.
This looks fine, can't go into 5.4 though because it changes globals
structure size and offsets, which is a BC break.
Should work for 5.5 though since we're not past feature-complete cutoff
y
Hi!
> Wouldn't it make more sense to have the ini consistent with the
> function name, sys_temp_dir?
Yes, I think it would. Alex, could you change it?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development
Hi!
> Zeev, for one, was one of them asking to have a 2/3 majority for any
> language related RFC. That's what applies to this RFC, and it is, as
> of now, accepted. I don't see how the vote is remotely close to a tie.
I'm sorry, I am seeing 34/21 result. It's 61% for, 39% against - which
means,
Hi!
> I mean more "no matter if it is or not", but the result is not tie
> anyway, accepted or not.
Remember we talked about this while discussing voting? What we have here
is a huge language feature (and, like it or dislike it, it is a big
feature which had a lot of effort, energy and though spe
Hi!
> what is the status of the rfc?
> were there any reasons why you didn't called for votes?
> Personally I would prefer named parameters also, and I think that we are
> too close to the 5.5 feature freeze, but somebody asked why did the
> progress stopped and I don't think that there were any s
Hi!
> What should we be voting on when voting on an RFC: on the RFC proposed
> feature, or on the patch itself?
Either, or both, depending on the RFC and the intent of the author. Note
that since there's rarely competing teams/patches on the same feature,
accepting the RFC means also accepting th
Hi!
> If we introduced BC breaks other than those, then we'd to review them
> and see why they have been introduced. But one thing is clear: we do
> not allow BC breaks between 5.x and 5.x+1.
We need a better definition of BC break then. Is deprecating an existing
feature BC break? Is adding a no
Hi!
> I've started a vote on CURLFile RFC:
> https://wiki.php.net/rfc/curl-file-upload#vote
>
> Please vote.
Looks like the feature has been approved almost anonymously, so I'll be
proceeding with merging the pull soon. I'm also planning adding __wakeup
there that blocks unserializing CURLFile,
Hi!
> Looks like the feature has been approved almost anonymously, so I'll be
Unanimously of course :)
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.p
Hi!
> ago I was once again confronted with errors under PHP 5.4. The module,
> responsible for the error: Content Access.
> http://drupal.org/node/1533186
I see there: Notice: Array to string conversion in
form_process_checkbox(). This means the module has a bug, and pretty bad
one at that, array
Hi!
> I've used this in other places, it's basically lightweight traits, and
> has always been perfectly valid code. There does not seem to be a clear
> justification for deprecating it other than, It's not the way 'some'
> people like code to work...
Well, I think the reason is that this code
Hi!
> Also can I obtain some information on the current state of new function
> extending regarding acceptance of a patch for bug #38917? (bug
> report/feature request at https://bugs.php.net/bug.php?id=38917)
The patch in this pull: https://github.com/php/php-src/pull/37 has some
memory leaks an
Hi!
> Can somebody shed some light why:
>
>
> echo new SplFileObject(__FILE__);
__toString is mapped to current() for SplFileObject:
http://www.php.net/manual/en/splfileobject.current.php
it's not documented for some reason, I think it makes sense to file a
docs bug on that.
--
Stan
Hi!
> There are situations where FPM/FCGI are not appropriate, or the server
> used does not support NTS (Apache windows for example, when fcgi is
> not an option).
Why Apache can't use FCGI? There's no proper driver os something in
Apache architecture prevents it from using FCGI?
> No. My idea
Hi!
> Of course an opcode cache isn't shred-nothing either, and maybe sharing
> opcodes within a process is faster than doing this in shared memory.
I don't think so. IIRC main time is spent of two things: building
runtime structures from storage formats (because we mess with our
structures in r
Hi!
> I don't doubt any of your abilities, what I do doubt is that how we
> can consider an outside project directly into the core. APC would
How it's more "outside product" than any of the other extensions we
brought to the core?
> without a doubt be up to pair if there was more people willingl
Hi!
> I like it. It would be totally awesome if it came with a webinar or
> something where Dmitry/Stas explain how it works though. Understanding
> how APC works has always been a contentious point. I'd be awesome if we
> could turn that around with O+?
Once the code is out there, I think it'
Hi!
> which shows the dreaded zend_optimizerplus.inherited_hack which mimics
> APC's autofilter hack. I'd love to get rid of this particular bit of
> confusion/code complexity on the integration.
Ohh, this one. IIRC that has to do with conditional definition of
classes and the fact that script ma
Hi!
I think having stuff on the wiki is nice, but for things related to the
code - e.g., APIs, builds descriptions, etc. - they should stay in the
code. They are easier to find there and easier to keep up-to-date, and
also ensure they have the content relevant to specific version. We could
have a
Hi!
> Python, for example, is thread safe by default. Extensions developers
Doesn't Python have global engine lock?
> It was and still is a lazy and design mistake to have focused on
> FastCGI to support PHP on IIS more easily, while everything else in
> this stack uses what the whole OS stack d
Hi!
> down. Right or wrong, good or bad, the gulf between PHP developer and C
> developer is *huge*, and doing anything at all with the PHP engine,
We're not talking here writing code in C. We're talking here typing
"configure" in shell, hitting enter, then typing "make" in shell, then
hitting
Hi!
> I did not check latest ICU code base but we never had any issues in
> intl in ZTS. However you are right, since 5.3.0 most TS issues were in
One of them has to do with number formatting, so if you have a number of
apps that use different locale settings on the same server, which have
differ
Hi!
> Right, but they do not give up thread safety. See "Thread State and
> the Global Interpreter Lock" in:
>
> http://docs.python.org/2/c-api/init.html
That's whole different concept of thread safety. It's basically saying
"you can do anything you want outside of Python engine but only one
thr
Hi!
> But this isn't that strong of an argument, and I think that following
> what SplFileInfo does would be more sensible (echoing the filename), but
> I'm not sure change would worth breaking BC for.
I don't see why it would be more sensible. It's different objects that
do different things - In
Hi!
> Because it was not developed at php.net for example? How many
I'm not sure what is the meaning here. Nothing is developed "at
php.net", strictly speaking. php.net doesn't have its own development
team that works exclusively for php.net, it just gets code contributions
from volunteers. And m
Hi!
> I did a testable version in javascript the other day. - it's similar to
> this..
Javascript is not really an OO language. It has objects, but it doesn't
really follow or enforce any of OO paradigms. It's prototype-based, so
things work differently there.
> An almost secret vote, that as I
Hi!
> I'm not against it but, just being curious, what are those security
> reasons ?
If you ever accepted serialized data from outside (say, after putting it
in a cookie or just having API that accepts serialization) and then
forwarded the same data array using cURL, the attacker could create
se
Hi!
> these onto the appropriate visualC / gcc types. As far as I can see,
> PHP doesn't and seems to use long and int almost interchangeably which
PHP indeed does not use fixed-size types in zvals, etc. but it
definitely does not "use long and int almost interchangeably". In almost
any place
Hi!
> About
> http://git.php.net/?p=php-src.git;a=commitdiff;h=79956330fe17cfd5f60de456497541b21a89bddf
> (For now, I have reverted this fix)
>
> Here some explanations.
>
> LONG_MAX is 9223372036854775807 (0x7fff)
> double representation of LONG_MAX is 9223372036854775808
I see wha
Hi!
> Stan, you are right to correct me. Sorry. However, I still feel that
> the implicit assumption is that sizeof(long) == 2*sizeof(int) and this
I'm not sure where this assumption exists. Could you be more specific?
PHP uses long for most integer values, and int for some internal things
and
Hi!
> On x86_64 (so, with or without -O2)
>
>
> $ gcc -O2 -Wall math2.c -o math2 && ./math2 9223372036854775807
> double=9223372036854775808
> signed=8000
> unsigned=8000
>
>
> On ppc64
>
> $ gcc -O2 -Wall math2.c -o math2 && ./math2 9223372036854775807
> double=
Hi!
>> This was I was afraid. That bug was just the tip of the iceberg. I
>> suggest we do change the the > operator to >= like you proposed,
>
> I will do it later today.
>= may be fine, but I am concerned about fmod change for 5.4. If we do
it, I'm afraid we may change some scenario, so I'd p
Hi!
> I blogged about how I have seen the RFC process working in practice:
> https://blogs.oracle.com/opal/entry/the_mysterious_php_rfc_process
Great article, thanks for writing it!
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Inte
Hi!
> Well, if it does block-level optimizations, that is already enough to
> make it useful for CLI-scripts, as even though caching is not relevant
> for long-running processes, optimizations should make things faster.
For most scripts, optimizations are not really worth it unless you run
the sa
Hi!
> A missing feature in PHP is a file system watcher/monitoring available
> for almost all platforms. On Linux, we have inotify (available in PHP
> through pecl/inotify), on Mac OS X, we have /dev/fsevents (not available
> in PHP, since we need ioctl to do that in pure PHP —and sudo—, no C
Hi!
> (A) The op-code optimization should be integrated into the core compiler
> and enabled through a GC(compiler_option) to be available to *any*
> opcode cache -- or to the application designer (by exposing these
> options through an INI directive.
Most optimizations would not give perceivable
Hi!
> Put simply PHP extensions should only reference the APIs exposed in the
> php headers. Zend has its own interface and extensions and since a Zend
> Opcode cache is SO intimately coupled with the Zend environment it makes
> sense to use a Zend extension to implement this. The whole idea of
Hi!
> a) The DateTimeImmutable class extends the DateTime class. Why was this
> done this way? Both classes are incompatible (as in the inheritance
They're not really "incompatible". Functions that do not modify dates
would work just fine. So it's "not 100% compatible", which is not the
same as i
Hi!
I've tried to build 5.5 on my Mac today and I got this:
Users/smalyshev/php-5.5/ext/sockets/multicast.c: In function
‘php_do_mcast_opt’:
/Users/smalyshev/php-5.5/ext/sockets/multicast.c:155: error:
‘MCAST_JOIN_GROUP’ undeclared (first use in this function)
/Users/smalyshev/php-5.5/ext/sockets
Hi!
> The pull request addresses bug fix/feature request #38917 implementing
> native signed public key & challenge support to the OpenSSL extension.
> Details can be found @ https://github.com/php/php-src/pull/267
I've looked into it and two things are missing:
1. Failure scenario tests. See my
Hi!
I remember we used to have a script that goes over bugs DB and closes
bugs that are in "Feedback" status for too long. Does it still happen?
Because we have bugs that are in feedback status for a long time: like
this one: https://bugs.php.net/bug.php?id=52961 - in Feedback for 2+
years. If the
Hi!
> Can you test this branch?
>
> https://github.com/cataphract/php-src/tree/mcast_mac_fix
This one builds fine for me.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
Hi!
> Wow, people are still serving web files over NFS? Sounds painful.
Sometimes, there's not much (better) choices if you need to keep
writeable files in sync over a number of machines. There are other
shared FSes but they would lead to pretty much the same issues.
--
Stanislav Malyshev, Soft
Hi!
> If no one objects, I'll merge this into 5.5 and master:
>
> https://github.com/cataphract/php-src/compare/dval_to_lval
Maybe add UNEXPECTED around the if condition? Since it's marked as
zend_always_inline I imagine it's supposed to be performance-sensitive...
Also, skip comments in tests
Hi!
> Yeah, but NFS, especially without the realpath cache, which you lose if
> you turn on open_basedir, is deathly slow because of all the stats.
>
> Typically PHP scripts are not actually "writable files" and the way to
> keep them in synch across multiple machines is to use a deploy
> mechani
Hi!
> echo date_create('@1361240634')->format('Y-m-d');
> // output: 2013-02-19
>
> echo date('Y-m-d',1361240634);
> // output: 2013-02-18
timestamp dates are created with UTC TZ, date() assumes your configured TZ.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(4
Hi!
I've created a pull to fix bug 49348 - when undefined properties do not
produce a notice when doing something like $this->undefined++, unlike
regular variables that do.
Unfortunately, this fix seems to require changing signature of
get_property_ptr_ptr(), adding fetch type, which makes it imp
Hi!
> and IIRC mwiki does 4 of these on a page render. Here a pattern based
> on (@include($file) == 1) is more cache-friendly.
This goes back to the fact that @ does not really disable errors - it
only disables reporting of the errors, but the whole message is
generated and goes all the cycle u
Hi!
> Johannes Schlüter in php.internals (Thu, 31 Jan 2013 16:00:17 +0100):
>> If no critical issues is found in this RC, the final version will be
>> released in two weeks.
>
> Just curious: what is keeping 5.3.22 and 5.4.12 from being released?
> Are there any issues?
We had 5.4.12 RC2 last we
Hi!
>> Also, I'm not sure I understand what 64-bit test is supposed to return
>> and why - why negative number is converted to positive one? What exactly
>> this change is supposed to improve?
>
> The least significant bytes are preserved. Take int(-2056257536) and
> int(2943463994971652096):
>
Hi!
> Yes, this is an overhead, but it is small beer compared to doing a
> getattr() RPC across the server room fabric to a NAS server backend.
That depends of what your error handlers do. Some may write to log
files, etc. if not configured properly (since error_reporting setting
doesn't have to
Hi!
> The problem with the argument that "everybody 'typehints' DateTime; we
> should inherit from it so that the code will run when the pass it a
> DateTimeImmutable" is that it assumes that everybody who typehints
> DateTime uses DateTime in a manner compatible with DateTimeImmutable. I
Hi!
> The idea of the fix is fine (I didn't check all the related changes in
> PHP extensions).
> I think it must be included into 5.5.
Thanks for reviewing it! If I don't head any objections in next couple
of days, I'll merge it to 5.5.
--
Stanislav Malyshev, Software Architect
SugarCRM: http:
Hi!
> To "accept a DateTimeImmutable" is not the same as "no recoverable
> fatal error when a DateTimeImmutable is passed". You can't possibly know
> whether passing a DateTimeImmutable is safe without reviewing the code
> on all the call hierarchy starting from where your DateTimeImmutable is
Hi!
> F.e., how long have we been battled for annotations? With all
> respects, it is about being blind and stubborn to say that PHP should
> not have annotations. But due to some "I'm happy with what we have
It is about being blind and stubborn to hold opinion different than
yours. And *this* no
Hi!
>
> p.s.: There is no reason why not to fix this in this way, I think,
There actually is. First, any option modifying engine behavior creates a
compatibility problem, since now the code that needs to work with it has
to check and be tested for yet another variable. Second, why does it
concen
Hi!
> Yes, but you can do an approximation. And in 99.999% of the cases 100
> will be enough. I can hardly imagine a case where you need to do over
> 100 implicit function calls. They should fit in every normal stack size of
> servers today.
Depth-first search in a modest-size data structure woul
Hi!
> You may use recursive functions (which are limited by the memory_limit),
> but if you use recursive magics, it's a design error. This is not the purpose
> of magics (, call_user_func(_array)?) and simply an abuse of the language.
I think you are confusing magic functions with internal funct
Hi!
> Don't consider it as a syntax change, only as a bugfix. It must have been a
> bug, that this degree of conformity was not yet reached. :-P
If it changes syntax, it's by definition a syntax change. It does not
matter if you think it should be changed and if you think it's a bug, it
still sho
Hi!
> - in some cases destruction of temporary result may cause destruction of
> final result
>
> ((object)(array("a"=>"b")))->a = "c"; // temporary object may be destroyed
> before assignment
I remember now this was somewhat of a problem - when the temp is
destroyed? I.e. I guess we could stick
Hi!
> Before drafting an RFC I would like to gauge interest in adding:
> get_object_constants and get_class_constants
>
> Currently this can only be done through ReflectionClass which is far slower
> than retrieving them directly from the constants table. Some simple
> timings show that through
Hi!
> May someone merge this PR (#290) as there are no arguments against it?
I just outlined arguments against it in my last emails. If your email is
not working properly and you miss some emails please check the list
archives.
> Or do I have to wait a little bit? (How long?)
In my personal opi
Hi!
> It's not a syntax change, but it is a very, very large engine change. Yes,
> it does not touch the Zend engine itself, but it adds a large amount of new
> code that is close to the engine. People doing engine changes will need to
> modify it too (thus it is quasi part of the engine, even if
Hi!
> If you are referring to APC as the stable cache, that unfortunately is
> not entirely correct, it is still relatively easy to crash APC unless
> some work-arounds are applied. I was speaking to a several people at
> the conference just yesterday and they were indicating frequent
> crashes wi
Hi!
> However, it does nuke several existing PECL extensions (some fatally). For
> example, XDebug has no compatibility with ZendOptimizer+ right now (at
> least that I could find, feel free to correct me if I'm wrong here).
This of course will have to be fixed before the release. Though right
no
Hi!
> Based off of the recent discussion around pulling in ZO+ into core, I've
> come to the conclusion that we should also pull in XDebug and Suhosin into
> core at the same time.
Suhosin has multiple BC-incompatible and performance-problematic changes
and limits and the author refused many time
Hi!
> It works fine. You just have to load ZO before xdebug. If you load it
> the other way around bad things happen. This wrong load order currently
Could you describe the bad things? Maybe we could have some checks in
either of them to prevent it... Of course, we could probably make ZO
just che
Hi!
> Just to put things in perspective, if opcode caches with extended info
> make it into the opcode cache - it's a bad thing. So it's actually
Yeah, we should definitely check for extended info and shortcut
compile_file immediately if that is there. Should be an easy patch, I'll
try to do pul
Hi!
Due to the fixes to CVE-2013-1635 and CVE-2013-1643 we're releasing PHP
5.4.13 RC1 and PHP 5.3.23 RC1 for testing a bit earlier. Both releases
can be found at:
http://downloads.php.net/stas/
Windows binaries will be available at:
http://windows.php.net/qa/
Please test this release and notify
Hi!
I've reviewed the pull 267 and it seems to be finally ready, at least I
can't see any problem with it. Is 5.5 still open for adding
self-contained functions or should it remain in master?
Thanks,
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext.
Hi
>
> - usage expression in write context (e.g. passing constant by reference)
>
> function foo(&$foo) {}
> foo("abc"[0]);
>
> - destruction of temporary result
>
> ($a . $b)[4]; // if ($a.$b) is destroyed?
>
> - in some cases destruction of temporary result may cause destruction of
> final
Hi!
> I've just renamed the NEWS files to a branch specific variant. NEWS
> files should not be merged up (as their contents are not linked) and
> they always cause a bit pain when doing automated things (such as the
> tzdb update).
I would really prefer first asking, then doing things to stab
Hi!
> Everytime I want to merge up from PHP-5.3 to 5.4 to 5.5 to master for
> the timezone database I get conflicts in NEWS, I don't even touch that
> file.
Did you set up git as described in
https://wiki.php.net/vcs/gitfaq#mandatory_git_settings ? Because I never
had merge conflicts in NEWS, i
Hi!
> I have never seen that, but I do consider that a hack. You will never
> get everybody to make that configuration. Feel free to revert it.
Well, I think it works reasonable well (it did for me). It is a hack,
but it gets the job done and it's pretty easy. Maybe it has to be more
visible or
Hi!
> I suppose we could use a .gitattributes file:
> http://blog.mindlesstechie.net/2012/08/17/always-keep-your-copy-of-a-particular-file-in-a-git-merge/
You still have to do git config with this solution. The whole problem is
that not everybody knows that it needs to be done.
--
Stanislav Maly
Hi!
> I'd to agree on one thing tho'. NEWS should not be manually edited.
> With or without git, it is a (relatively small) pain. Back to the git
> migration time, David and I discussed about generating it from the
> commit messages. That implies to enforce a commit message format, a
> 1st attempt
Hi!
> RFC updated.
>
> Any other comments about this RFC?
Could you provide a use case for this - which practical value this has?
It also still contains factually incorrect claim that unset() is a
function and that there's some "inconsistency" in the fact that it does
not return value.
Also, i
Hi!
> so I stumbled upon this bug report: https://bugs.php.net/bug.php?id=64357
>
> It's fairly easily fixable, but I don't know if it's even a bug... The
Well, the result in the bug is obviously wrong - it should have one
date, or another date, but not both! I'd say if you explicitly set the
Hi!
> Shouldn't this fail a little bit more obvious (-> "loud")? And how is
> this even possible?
Well, for example - __unset is required to do X before unsetting
variable but X fails for one reason or another and the logic dictates
that you can not unset unless X is done (for a real life example
Hi!
> The main practical value is in the __unset magic method. You can now
> communicate through the "proper" way of a language construct with an
> __unset method. (success or failure)
I'm not sure how useful is that based on your example - unset could
throw the exception as well... And the whole
Hi!
> I have run into a bug, which is open since 2009. It would be nice if
> you could look at https://bugs.php.net/bug.php?id=47336 It has been
> marked as “documentation problem”. But in my opinion the
> implementation should follow the documentation and allow fopen
> “data://” streams even if “
Hi!
> why not enable then this "getCallback()();"?
There's an RFC for that: https://wiki.php.net/rfc/fcallfcall
but it has some edge cases which I didn't have time to figure out yet.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP In
Hi!
> Also, AFAIR, call_user_func() doesn't work with functions using references
> in args.
Use call_user_func_array() for that, it supports refs.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Ma
Hi!
> Use call_user_func_array() for that, it supports refs.
>
>
> Isn't it since 5.3 or so ?
I think it always has been this way. See: http://3v4l.org/CGCLS
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtim
Hi!
> as you are aware we delayed the first beta by about 4 weeks to get
> Zend Optimizer in. This week will finally see the release of the first
> beta. This implies:
>
> No new features should be added to the PHP-5.5 branch from now on!
>
> RFC that are currently in voting phase can be merge
Hi!
> We've had a problem recently where one of our developers forgot an "if".
We clearly have two contradicting directions here. On one hand, we have
people that say giving '1' to a method expecting integer should be an
error, and anything unexpected should generate warnings and errors
because t
Hi!
> - In “Backwards Incompatible Changes” there’s a big list of BC
> changes that are internals and don’t impact user land. So could come across
> a lot more intimidating than it is. I think we should move towards the end
> of the upgrade notes in a section of its own that’s “PHP Intern
Hi!
> just FYI, there's some non-portable code in Zend OpCache (alpha5 was built
> just fine), which prevents building of php5 beta1 on non-Linux systems:
>
> FreeBSD: https://bugs.php.net/bug.php?id=64490
> Hurd i386:
> https://buildd.debian.org/status/fetch.php?pkg=php5&arch=hurd-i386&ver=5.5.0
Hi!
> It seems that GNU Hurd does implement flock(). I'll talk to Debian
> porter team if they can help with the issue there.
I suspect it does, the question is - how... Everybody has different
struct flock, with same members in different order :( I'll try to add
some configure magic to at least
Hi!
> http://lists.debian.org/debian-hurd/2013/03/msg00016.html
>
> Should I fill the bugreport, or you will pull it from here?
I'm working on more generic solution, will have patch in a day or two,
if you could check it on Hurd it'd be great.
--
Stanislav Malyshev, Software Architect
SugarCR
Hi!
> http://lists.debian.org/debian-hurd/2013/03/msg00016.html
>
> Should I fill the bugreport, or you will pull it from here?
Could you check if this pull:
https://github.com/php/php-src/pull/314
Makes it better?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(
Hi!
As many probably know, unserialize() has a security issue following from
the fact that you can create objects with data from unserialize(), and
these object may have behavior that is invoked automatically - namely
__destruct - that can result in unintended results. See e.g.
http://heine.famili
Hi!
> I think Stas proposes a solution to the problem and I think Anthony
> proposes a viable alternative. I would say that Anthony has found the
> shortest distance between the two points (the problem and the solution),
> however.
The fact is that people do use serialize() for data that may be
Hi!
We currently have around 40 RFCs on the wiki under "Under Discussion"
section, but many of them aren't actually being discussed and hasn't
been for long a time. This makes the issues that are actively
discussed/worked on hard to find. How about taking those that had last
change more than coupl
Hi!
> And what about automatic un/serialize() of objects in $_SESSION?
> People don't even see those function calls in their code, so dropping
> the function/ality would be a wildly drastic move.
Nothing about it, the change is for unserialize() function.
> tread gently, as in your suggestion of
Hi!
> Yeah, well, the people who do that are also the ones that are unlikely
> to make use of the new parameters to secure themselves. In order to make
Why? Making use of one parameter is orders of magnitude easier than
refactoring your whole application to not use serialize() (especially if
you
701 - 800 of 1273 matches
Mail list logo
