Hi!
On one side there's a clear BC break which, according to the related
RFC, is to be considered as a blocker, on the other one, a strong and
valid argument regarding spreading additional server variables.
I'm not sure being late in the release process is truely a valid
argument for accepting
Hi!
Hi:
I have reset the vote, only vote for trunk now.
https://wiki.php.net/rfc/constdereference
What happens in your patch if something like ['foo', 'bar'][1] is used
in write context?
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900
Hi!
3. $d-setTimestamp(1000) is not ever going to work as
zend_parse_parameters simply gives me long: 1215752192. This I find
really strange actually. Any clue?
That's probably float to long conversion, since 1000 is float on
32-bit.
--
Stanislav Malyshev, Software
Hi!
I'll have a look when I get back home.
Thanks!
Is there anything else you want me to look at?
Yes, it would be nice if you could check out XFAILs, especially the one
that crashes (53437) but others too.
Thanks in advance,
--
Stanislav Malyshev, Software Architect
SugarCRM:
Hi!
I see that test for bug 52062 (marked as fixed by this commit:
http://svn.php.net/viewvc/?view=revisionamp;revision=320481) now fails
on my 32-bit system. Looking at the patch and the test, it can not
actually succeed, as the test expects this:
int(1000)
which is not possible on
Hi!
It's not only bad for merges, also confusing with blame/annotate while
identifying the reason for bug.
As soon as we move to git, IIRC git has ability to separate ws-changes
from non-ws ones and do diffs/history while ignoring ws. I didn't figure
out if you can do non-ws merge (I
Hi!
Could we maybe keep this discussion contained to return value type
hints please? Optional variable type hinting is a completely different
topic that would require a separate RFC and implementation. If you are
interested in this you can propose a RFC for this.
Actually, as I said many
Hi!
That said, PHP is not Java, and type hinting in PHP is very
different. It is, in fact, type *hinting*. This is a runtime
feature. Only interface validation is verified at compile time, so
we have to consider performance vs. feature in these cases.
Naming it hinting was probably the
Hi!
function age_check($age)
{
if (!is_int($age)) {
throw new InvalidArgumentException;
}
}
With the above code, the caller needs to cast and the writer of the
age_check() function has to copy/paste/adapt these checks to all the
correct
Hi!
is_numeric is not good enough in some cases, like when searching for value
in MongoDB where it matches agains typed value.
function age_check(int $age)
{
// do stuff
}
This would require less code, easier to read and will catch wrong type at
runtime
Hi!
What I mean is that you can catch recoverable fatal error in your error
handler and at least be notified of what happened. Yes, you cannot go back
in your script to corrent anything after that but you can show a detailed
error message and send error email to developer.
Just the same thing
Hi!
I'm going to have to disagree with you there. Type hinting DOES save
me a LOT of effort in development. I can stop worrying about checking
to make sure the parameter that I got is what I want it to be, and
just use it. The runtime will check and enforce that for me. When
I'm sorry but
Hi!
Most modern languages allow returning null in any case. This is a hail
Mary in the event something happens, but throwing an exception is
inappropriate. I see no reason to diverge from that.
In PHP, returning object if everything is OK and false if not is a very
common pattern.
Also, you
Hi!
Are you suggesting not allowing null to be returned, or provide an
indicator within the syntax that it may return null? PHP would be the
first language I'm aware of that would do so in either case.
No I am not suggesting that. I'm just pointing out the problems with the
concept of
Hi!
And in those cases, they would continue to use the keyword function
and be considered unknown as they are today.
Taking the most common case and ignoring it and saying ok, then don't
use it is not a good way to design a feature in a general-purpose
language that would be used by
Hi!
BTW these are failing in head at present - I guess somebody is working
on them...
globals in global scope [Zend/tests/globals_001.phpt]
globals in local scope [Zend/tests/globals_002.phpt]
globals in local scope - 2 [Zend/tests/globals_003.phpt]
globals in local scope - 3
Hi!
This can never be portable, because Windows doesn't even bother keeping
historical timezone rules. They only have: current normal UTC offset,
current DST offset and rules on when there is a transition between.
Well, that closes the question for Windows, but in theory we maybe could
Hi!
This should implement the isset() return false, and accessing producing
a warning (but 'less' BC by returning the first character)
https://bugs.php.net/patch-display.php?bug_id=60362patch=isset_changed_warning_only_on_access.patchrevision=latest
Hi!
I think the idea behind this patch is good. I'll do final checks and
apply it tomorrow if no objections heard until then.
Some notes:
$s = string; isset($s['offset']) returns false
This is pretty critical, as it's the only way to detect this situation,
and ensure that array tests do
Hi!
I think only trigger notice when a convertion of string to number
index is a good way (trivial bc break).
This however doesn't solve the problem with isset() (which still
produces true then). BTW, notices there may lead to interruption
problems (imagine some error handler that may
Hi!
* There will be a new time zone called System. When this time zone is
active, instead of PHP's internal time zone database and
timezone-aware code, system-provided local time APIs are used. In
Which APIs do you mean? I imagine it might be possible (note - just
might be, no guarantees
Hi!
I believe he's referring to sys/time.h, but this introduces
portability issues. If it were just unix, that would be one thing.
But maintaining this and a Windows alternative, and I have no idea
what that is, is not worth it IMO.
Yes, portability is questionable. Though if we had a good
Hi!
On 14/12/11 22:53, Will Fitch wrote:
I believe he's referring to sys/time.h, but this introduces
portability issues. If it were just unix, that would be one thing.
But maintaining this and a Windows alternative, and I have no idea
what that is, is not worth it IMO.
time.h is present in
Hi!
Note that despite I wrote the patch, I'm -1 on it, as stated in the
previous message in this thread.
So what you prefer to do instead? I'd like to have ob_gzhandler(), but
if you think it can be done better way, please advise.
--
Stanislav Malyshev, Software Architect
SugarCRM:
Hi!
I don't want anyone to take it personal... But what is the status about
missing ob_gzhandler function (but also ob_tidyhandler and
ob_iconv_handler) ?
I put mike's patch and a comment to help track the BC break /potential
inconsistency :
https://bugs.php.net/bug.php?id=60326
Ah, I
Hi!
I believe the attempt with the RFC was to mimic the syntax that C#
went with, the RFC is here:
https://wiki.php.net/rfc/propertygetsetsyntax
Reading this RFC I notice it makes get/set keywords. This would lead to
huge amount of breakage in existing code, so I strongly suggest to look
for
Hi!
Since it is just adding new separate structure to session module, but
PHP itself checks API version number. So users cannot use the same
binary module anyway. I should have said API, not ABI.
Now it should compile with msession which uses PHP_MOD_SID/PS_MOD_FUNCS_SID.
That's the problem.
Hi!
For example, it is easy to find cases with google code search, that
users are setting ID while they really should do is
session_regenerate_id(). These kind of mistakes would be better to be
prevented under strict mode, IMHO.
I'm not sure how that would help in this case - so the set
Hi!
if (!(($validator = new SomeValidator())-isValid($value))) {
// Validation failed, get messages...
$view-assign('errors' = $validator-getMessages());
return $view-render('error');
}
// validation passed, do something...
Yes, this could be written
Hi!
If user really want to set session ID, they can explicitly disable
use_strict_mode.
For almost all application, setting static ID is bad code. There are
some applications that exploit adoptive session, but they can live
with new code also.
I'm not sure I understand - why prohibiting the
Hi!
My main concern with this change is that it is binary incompatible with
existing session implementation, which means it would be hard to get it
into 5.3 and 5.4. While I understand sometimes adding handlers is
inevitable, in this case I'm not sure why it is required. So far the
only
Hi!
Hi all,
I though I've better to start new thread, since I changed the status
to Under Discussion.
This is RFC for making PHP session strict.
https://wiki.php.net/rfc/strict_sessions
I'll implement DoS protection later, since current patch pretty well
tested and suitable for PHP 5.4/5.3,
Hi!
That would help a lot ... this is not a problem of so the developer can fix his
code but rather so we can fix legacy code which other non-developers are
currently using happily ... If *I* had written the code I would not have done it
the way it is currently structured, but I'm not about to
Hi!
This is going to be a huge problem for Drupal. Drupal uses deep
associative array structures a lot, by design. That means we isset() or
empty() on arrays a lot. I haven't had a chance to test it yet, but I
see this change breaking, um, A LOT. And as Daniel noted, the fix is to
turn one
Hi!
For all the people saying, Revert. You guys realize that also means we
revert all the array dereferencing we added elsewhere, right? That
includes function array dereferencing which pretty most everyone has
been clamoring for for years.
I think you're underestimating it. We'd have to
Hi!
I've committed support for UTS #46 to 5.4 and trunk.
See http://svn.php.net/viewvc?view=revisionrevision=319770
Could you please also fix the protos on the functions? And updating the
docs would be ideal :)
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
Hi!
Technically, yes, it is possible. But is it desirable? It would require
breaking the abstraction and looking at the actual values of the flags,
choosing one of the unused bits (possibly a high one) and hope it'll never
be used in future. Plus, in the current patch, the value of the variant
Hi!
On 11/23/11 12:56 AM, Lester Caine wrote:
I'm having a lot of trouble with working out WHAT is going on here at all.
It's actually very simple. Take variable $a which is a string (foo).
Now it you do $a[0] that would produce first letter - f. Now here's a
tricky part - if you do
Hi!
I thought that we already agreed using an output argument for getting
the specific error instead of returning either a string or an array.
That's what I was thinking too, but Gustavo seems to plan to do mixed
return, which I think is a worse option.
--
Stanislav Malyshev, Software
Hi!
On 11/23/11 6:14 AM, Daniel Convissor wrote:
To me, this is the bug. $a['blah'] does not exist. An undefined index
If it's a bug, this bug was in PHP since forever, nothing new here.
notice should be raised. The key blah should not be converted to 0.
The following two things should
Hi!
Unless I'm mistaken it seems that we have a clear and vicious BC break
here, the kind of changes that are annoying to catch and does not
No, we do not have a BC break here, we have a bugfix here that makes
string ops work consistently and only has a problem with completely
broken code.
Hi!
The only case where the 5.4 branch works differently as before if you
reference a string type(int, float, etc. won't trigger this) variable
using an associative index and you expect it that to be undefined
variable even though that the documentation explicitly states that the
Actually,
Hi!
These escape functions are not mandatory, but these functions increase
usability of PHP and pgsql module.
Do you think it is ok to merge the patch to 5.4 branch?
Unless there's a very compelling reason for that (i.e., security
implications, missing support for a widely used part of
Hi!
I have been using news.php.net ML archive a couple of times lately, and
I must say unfortunately it's not the best ML archive I have seen
around. No search, no indexing by date/topic, references are sometimes
messed up, etc. So my question is - isn't it the time to upgrade it to
some
Hi!
You mean hosting our own, or using some third party service?
Usually I prefer http://www.mail-archive.com/internals@lists.php.net/
Unfortunately not all of our lists are mirrored there.
Well, yes, I know there are various places where PHP lists are archived.
My point is if we have
Hi!
The fix to make $a[0][0] work is good. No argument here.
Then the rest of the discussion is moot for 5.4, as that's the only
change that happened.
The problem arises where programmers wrote code anticipating the
incoming variable is an array but another programmer has passed in a
Hi!
As distasteful as it seems, it absolutely should be reverted IMHO.
You seem to misunderstand something here. This behavior is a direct
consequence of string offset result being a string. To revert it means
to reintroduce broken string-offset pseudo-var-type that led to huge
amount of
Hi!
If you want this fix to be palatable, we'll need a new language
construct that effectively runs a series of is_array array_key_exists
with a final !== null check.
I'm not sure RC time is a good place for introducing new language
constructs. Actually, I'm pretty sure it's not.
--
Hi!
But neither is introducing a potential bomb of the kind that the 'date' saga
created. The problem this change IS causing is likely to hit many live sites
The claim that many live sites actually regularly use string multiple
string offsets to distinguish strings from arrays sounds
Hi!
And I believe you're missing the point. I'm not suggesting it for 5.4,
but illustrating that until something like it (or better) exists, the
bug fix should wait until such a solution exists.
Again, you seem to miss the major point. The bug fix was fixing the
result of string operation,
Hi!
On 11/22/11 6:36 PM, Etienne Kneuss wrote:
PEAR is definitely doing some strange things :) Is it checking indices
of a variables without checking first if it's an array?
Sounds like the comeback of Please don't break bad code! seen with is_a :)
I think somebody should start a code cleanup
Hi!
First of all, I would like to politely ask everybody on the list to
change subject if, well, subject of the discussion changes. I was
totally under impression that this topic still discusses libidn2
extension in PECL and might miss discussion about intl IDNA patch if
David didn't point
Hi!
We're still missing some docs for new 5.4 stuff, and I think it'd be
great to have it covered by the time of the release. These parts are
completely missing from the manual:
- Syntax: Short array notation, callable type in function args
- Classes: ReflectionZendExtension, SessionHandler
Hi!
That is incorrect, not every timezone DST change is 60 minutes.
The I would guess this code in do_adjust_timezone() also wrong:
case TIMELIB_ZONETYPE_ABBR: {
timelib_sll tmp;
tz-is_localtime = 1;
tmp
Hi!
For fixing the TLA / Zone Type 2 bugs, focus on the following tests:
bug55253.phpt
rfc-datetime_and_daylight_saving_time-type2.phpt
Those are exactly the two xfails fixed by my patch.
DateTime_*-type2-type2.phpt
These aren't fixed but it may be related to the
Hi!
I'd like to commit a one-liner to 5_4/trunk if there are no objections.
See it in the attachment.
Stas, do you mind if I commit it to 5_4 now?
I think it's ok.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi!
We're in RC now, and I'm very concerned about the status of DateTime
functionality (see bugs 60236, 60237 and XFAILs) - I've reported these
problems in June, but not much happened since then. I'm trying to figure
out what's going on there, but I'm not sure if I understand the code
Hi!
I recall from earlier discussions that Stas was in favor of reverting
this change -- what's the status at this time? This single change
I was not and still am not - I think if something warrants notice this
is exactly the case. Conversion of array to string Array IMHO makes no
Hi!
First of all, ob_clean() and ob_end_clean() will raise the same
notice even in PHP 5.3. It seems inconsistent to me to treat these
three differently, so in that regard, PHP 5.4 is actually fixing
behavior (although arguably the other way to approach the problem is
to remove the notice from
Hi!
What did people use ob_gzhandler for directly?
Well, apparently they did for some reason, doing custom output handlers
based on it I guess. So the question is - is it possible to still have
this function implemented?
--
Stanislav Malyshev, Software Architect
SugarCRM:
On 11/13/11 7:11 AM, Laruence wrote:
Hi:
this revisioin remove the ob_* functions:
http://svn.php.net/viewvc?view=revisionrevision=299980
Indeed, I do not see ob_gzhandler in the function list, but no mention
of that in UPGRADING or other docs. As far as I understand, it was
converted from
Hi!
That's unless the spl_autoload_register() api changes and allows to deal with
errors - require(), Exception, ...
Autoloader shouldn't produce external errors - because if it's unable to
load class, others may be able. Also, it'd be quite hard to handle such
errors - you'd have to guard
Hi!
But blocking the only thing so many PHP projects have ever agreed on
is a major mistake. And it is a political and religious choice
(religious as in php does not enforce standard). Even for something
that does not enforce anything if not used.
Nobody's blocking anything. I don't
Hi!
can keep dreaming about our famous let make it easy to people to
contribute, it won't work as we are not willing to give them a voice.
I don't think one implies the other. If one helps PHP project it's
great, really, but that doesn't mean one can have his pet feature pushed
through over
Hi!
See the votes, there is a patch, created by people able to maintain
it. It is especially obvious in this case as this RFC is supported by
a large part of our users.
Able != will. There are tons of people able to fix bugs in PHP, yet some
stay unfixed for years.
Supported by users doesn't
Hi!
well even for proposals which got accepted. This is not about specific
proposals but about this exact discussion to go back to our old model.
I'm totally against it. That will kill any effort we have put to get
more contributors and feedback or help from our users.
Nobody talks about
Hi!
Sure, but this is another great example. If you wrote an RFC that
basically said, Let's rewrite the engine I bet it would get a lot of
We already have such proposal. It's called unicode support. Everybody
talks about how great it would be to have one. If we had a vote, I bet
there would
Hi!
As long as it is completely obvious what is being voted on and the
process is followed, the voting RFC rules are fine. It would be nice
though if we could iterate in order to get 2/3 approval on most
proposals. It is these 50/50 ones that are problematic and often boil
down to half the
Hi!
This is actually already supported.
The SplClassLoader$mode does exactly that. The $mode can be one of these values:
- MODE_NORMAL: Throws error while attempting to include an unexistent file
Why this should even exist? It's never OK for generic autoloader to
produce any errors when it
Hi!
- I think it's too late in PHP 5.4's release cycle to be proposing
anything for 5.4.
Not talking about the merits of the loader, if it comes into 5.4, that
won't be 5.4.0. Unless we discover some very bad problem, 5.4 is going
into RC tomorrow, which means I will be extremely reluctant
Hi!
To summarize: The technical viability of a feature should always be determined
through discussion before voting even starts.
It doesn't matter too much when it happens, as the purpose of the vote
is to see if the feature is needed/desired in the form that is proposed.
That doesn't mean
Hi!
What I should have said is that in my eyes - as outlined in my other replies -
I don't see any compelling reasons why one should distinguish between php-src
contributors and the others.
Because the premise here that PHP contributors understand PHP, it's
ideas, limitations, history,
Hi!
tools' project leaders. By denying the voice of them is almost the
same as telling there's meritocracy only if you contribute with the
language internals.
Nobody's denying voice to anybody. Anybody who's interested can feel
free to come to the list and bring forward their arguments and
Hi!
This attitude only makes me lose a lot of time answering questions
instead of focusing on actual RFC stability. I want to propose
something stable, I do not want to be pressured about should the RFC
exist or not. It only delays the real voting results. What I can do to
address this?
I
Hi!
On 11/8/11 1:34 AM, Yasuo Ohgaki wrote:
It seems copypaste from a message don't work well.
Try running some script, not -v. IIRC -v doesn't initialize request.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP
Hi!
On 11/08/2011 01:39 AM, Florian Anderiasch wrote:
So it looks like only FPM uses it for more than the default behaviour of
terminate, from a quick glance.
Not deferring SIGUSR2 just because valgrind on OSX doesn't like it isn't
really an option here. We could make debug builds on OSX not
Hi!
On Sun, 6 Nov 2011, Stas Malyshev wrote:
2. DateTime fixes with TLA timezones
Please remind me the issue number?
The issue described here:
http://www.mail-archive.com/internals@lists.php.net/msg51463.html
and all XFAILs we have in the test suite.
I can't find this issue in the bug
Hi!
Is_a has a patch attached to the bug. Tests pass etc.
I'm looking at bug 55475, there are two patches there:
is_a_5.4_alternative and final_patch_for_5_4_and_HEAD. Which one do you
mean?
The latter has:
- if (zend_lookup_class_ex(class_name, class_name_len, NULL, 0, ce
TSRMLS_CC) ==
Hi!
It was ignored to death, even though there is a(two) patch for it.
https://bugs.php.net/bug.php?id=54089
I've applied the patch for that.
On a related note, I would also like to see
https://bugs.php.net/bug.php?id=60164 fixed.
Patch with tests attached to the bug would be helpful :)
Hi!
I've noticed that if I run PHP 5.4 under Valgrind on my Mac, I get this:
Fatal error: Error installing signal handler for 31 in Unknown on line 0
Could not startup.
Indeed, valgrind says:
==47112== Warning: ignored attempt to set SIGUSR2 handler in sigaction();
==47112== the
Hi!
We have the following issues which I'd really like to put behind us
before RC (please correct me if they already were resolved):
1. is_a issue - did we resolve it? If not - does anyone have a proper
patch and can make it before RC scheduled date?
2. DateTime fixes with TLA timezones
3.
Hi!
On 11/5/11 2:04 PM, Peter Cowburn wrote:
Other examples which describes the feature at
http://wiki.php.net/rfc/instance-method-call
Thoughts?
Bump.
What's the current status on this?
It would be nice to this teeny little patch in for 5.4.0 if possible.
I think the brackets one is
Hi!
Hi:
like the following script:
?php
$str = (string)array();
echo $str;
it is obviously intentionally convert a array to string , but the
warning is coming:
I think it's the correct way to react for PHP. This code is an extremely
convoluted way to write echo 'Array'; and as
Hi!
Please take a moment to review the DateTime transitions RFC and vote on
it. I encourage voting on it to ensure we are all on the same page as
to how PHP will handle transitions. Voting is open through 10/31.
Reading this RFC, I have some questions:
1. Would this ST/DST be used on
Hi!
If you don't know it, don't pass it in! Then PHP will guess, just as it
does now and always has done. It's just an extra help in case you need
to be specific about whether you want the ST or DST variant of 02:30.
You can just use EDT/EST anyway, and that would work too (but of course
not
Hi!
On 10/24/11 9:45 AM, Mike Willbanks wrote:
By standardizing this inside of an extension gains us 2 very major features
(IMO):
But we already have the extension, don't we?
From the RFC prospective it does seem like many things are missing:
1. Examples
* The easiest example being that of
Hi!
https://wiki.php.net/rfc/datetime_and_daylight_saving_time
I will move this to voting phase tomorrow unless I hear objections.
Not an objection but more a side question - is this related to fixing
TLA timezones in general? Right now they fail in a multitude of
scenarios which have
Hi!
You want the DateTime DST fixing RFC
(https://wiki.php.net/rfc/datetime_and_daylight_saving_time) implemented
before RC1, right? If so, keep in mind that voting on it will start
tomorrow and finish on November 1. Then someone needs to implement
it. The deadline may need adjusting.
As
Hi!
On 10/22/11 2:36 AM, Nathan Nobbe wrote:
Hi,
Another old issue I'd like to rehash with the upcoming release around the
corner [1].
I patched 5.4 alpha2 for review [2].
I think better idea would be to add another API function
(zend_call_method_ex?), that implements arbitrary argument
Hi!
ESR proposes his help to OSS projects in converting SVN projects to Git:
http://esr.ibiblio.org/?p=3839
Just thought it might be interesting.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development
Hi!
On 10/19/11 3:23 AM, Felipe Pena wrote:
What about https://wiki.php.net/rfc/instance-method-call?
I'm not sure what would be the use case for that... But if people need
it, and there's no objections, I don't see any danger in including it.
If we do, we need tests though!
--
Stanislav
Hi!
On 10/21/11 4:00 AM, Lester Caine wrote:
So I suppose the question I have to ask is what the f**k am I doing wrong on the
windows setup? I've always known that linux was faster, but 4 times faster on
the same hardware? My main development machine is giving 27.750 seconds which is
even
Hello!
I've packed PHP 5.4.0beta2 which you can find here:
http://downloads.php.net/stas/
The Windows team provides windows binaries which you find here:
http://windows.php.net/qa/
Please test it carefully, and report any bugs in the bug system, but
only if you have a short
Hi!
On 10/18/11 11:28 PM, Patrick ALLAERT wrote:
I have not enough karma to change Zend/zend.c.
Could you solve this please?
Once solved I can push this to trunk and PHP_5_4.
If you send me the patch I can apply it.
--
Stanislav Malyshev, Software Architect
SugarCRM:
Hi!
Since we have next release planned on 20th, and since we have at least
three unsolved issues for 5.4 yet which we expect resolution soon:
- is_a question
- serialization changes
- date fixes
I think the release on 20th should be beta2 and we can start the RC
cycle once these are
Hi!
On 10/18/11 12:36 PM, Pierre Joye wrote:
where is the question? You seem to be the only one to disagree with
the revert and the proposed patch. Rasmus and other agreed on it
already, here and the security list.
The patch is still not applied. If nobody agrees with me - ok, apply it
then.
Hi!
On 10/18/11 2:43 PM, Alain Williams wrote:
It probably does, but it is quite subtle. I was expecting the above to work
since
it does in C -- although in Cvariable is an address which can be used in an
expression ... the PHP '' operator is different, in spite of apparent
similarities.
Hi!
On 10/16/11 5:54 PM, Sebastian Bergmann wrote:
Such a performance regression sounds like an appropriate punishment to
me for deploying bad code ;-)
By bad code you mean not obsessively checking for stuff that is of no
importance to them as programmers and is only required because
Hi!
On 10/17/11 6:01 AM, Patrick ALLAERT wrote:
@Stas, DSP
Would you agree to merge this into PHP 5.4?
*bump*
Yes I think it's OK.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To
Hi!
On 10/16/11 3:39 AM, Pierre Joye wrote:
There was example codes in previous discussions, here and on security.
The document used for the CVE assignment has some as well.
http://www.byte.nl/blog/2011/09/23/security-bug-in-is_a-function-in-php-5-3-7-5-3-8/
1101 - 1200 of 1748 matches
Mail list logo
