Hi,
Thanks to Nexcess, we have a new wonderful machine for http://gcov.php.net
up and running.
This new machine is running linux 64 bits, so expect a few differences in
the test results.
I believe most things are ported from the old machine, including all
daemon's configurations.
I fired an experimental run of the cron job. Please help me by reporting
extensions that are not enabled, daemons that are misconfigured and why (and
therefore some tests are failing or skiping), missing valgrind suppressions,
and so on.
Thanks to Nexcess for offering a new machine to replace the old one.
Nuno
2011/7/23 Nuno Lopes nlopess@php.net:
Hi,
Thanks to Nexcess, we have a new wonderful machine for http://gcov.php.net
up and running.
This new machine is running linux 64 bits, so expect a few differences in
the test results.I believe most things are ported from the old machine, including all
daemon's configurations.
I fired an experimental run of the cron job. Please help me by reporting
extensions that are not enabled, daemons that are misconfigured and why (and
therefore some tests are failing or skiping), missing valgrind suppressions,
and so on.Thanks to Nexcess for offering a new machine to replace the old one.
Nuno
Nice! I see the mail now works too. :)
Thanks Nuno++
--
Regards,
Felipe Pena
Thanks Nuno, great job!
Hi,
Thanks to Nexcess, we have a new wonderful machine for http://gcov.php.net
up and running.
This new machine is running linux 64 bits, so expect a few differences in
the test results.I believe most things are ported from the old machine, including all
daemon's configurations.
I fired an experimental run of the cron job. Please help me by reporting
extensions that are not enabled, daemons that are misconfigured and why (and
therefore some tests are failing or skiping), missing valgrind suppressions,
and so on.Thanks to Nexcess for offering a new machine to replace the old one.
Nuno
--
Wbr,
Antony Dovgal
http://pinba.org - realtime profiling for PHP
Thanks Nuno, great job!
Hi,
Thanks to Nexcess, we have a new wonderful machine for http://gcov.php.net
up and running.
This new machine is running linux 64 bits, so expect a few differences in
the test results.I believe most things are ported from the old machine, including all
daemon's configurations.
I fired an experimental run of the cron job. Please help me by reporting
extensions that are not enabled, daemons that are misconfigured and why
(and
therefore some tests are failing or skiping), missing valgrind
suppressions,
and so on.Thanks to Nexcess for offering a new machine to replace the old one.
Nuno
Excellent work.
I see from the recent report that there are a LOT of similar warnings.
I'm guessing that those warnings, whilst they are generated on a linux
x64 box, would be the same for win32 (and anything else).
What sort of policy is needed in addressing casting warnings like
this. I get a LOT of warnings about casting of doubles/floats to
ints/longs, along with the potential for potential data loss.
How feasible is it to aim for a 100% warning free build? I'm not
meaning that we should suppress the warnings.
--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea
In my experience, 100% warnings free is only practical in two cases:
- When the project is built with that policy from day one.
- When someone takes the (I'd estimate) two weeks solid work
necessary to eliminate every existing warning from the current trunk,
AND a strict policy of maintaining zero warnings is put in place.
(Believe me, the policy doesn't work if there are any warnings in the
build; people inevitably get lazy.)
Given the variety of warnings that pop up in a PHP build (and don't
even start me on the list thrown up by Clang's static analyzer!), it's
a major undertaking to eliminate all the warnings, and it'll get ugly.
-- Gwynne
Thanks Nuno, great job!
Hi,
Thanks to Nexcess, we have a new wonderful machine for http://gcov.php.net
up and running.
This new machine is running linux 64 bits, so expect a few differences in
the test results.I believe most things are ported from the old machine, including all
daemon's configurations.
I fired an experimental run of the cron job. Please help me by reporting
extensions that are not enabled, daemons that are misconfigured and why
(and
therefore some tests are failing or skiping), missing valgrind
suppressions,
and so on.Thanks to Nexcess for offering a new machine to replace the old one.
Nuno
Excellent work.
I see from the recent report that there are a LOT of similar warnings.
I'm guessing that those warnings, whilst they are generated on a linux
x64 box, would be the same for win32 (and anything else).What sort of policy is needed in addressing casting warnings like
this. I get a LOT of warnings about casting of doubles/floats to
ints/longs, along with the potential for potential data loss.How feasible is it to aim for a 100% warning free build? I'm not
meaning that we should suppress the warnings.--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea
I would add:
2.1 fix the new ones
That's what I try to do using a delta between two revisions. At some
point these delta will be available online so anyone can fix them as
well, including the author of these new warnings.
On Sun, Jul 24, 2011 at 12:36 AM, Gwynne Raskind
gwynne@darkrainfall.org wrote:
In my experience, 100% warnings free is only practical in two cases:
- When the project is built with that policy from day one.
- When someone takes the (I'd estimate) two weeks solid work
necessary to eliminate every existing warning from the current trunk,
AND a strict policy of maintaining zero warnings is put in place.
(Believe me, the policy doesn't work if there are any warnings in the
build; people inevitably get lazy.)Given the variety of warnings that pop up in a PHP build (and don't
even start me on the list thrown up by Clang's static analyzer!), it's
a major undertaking to eliminate all the warnings, and it'll get ugly.-- Gwynne
Thanks Nuno, great job!
Hi,
Thanks to Nexcess, we have a new wonderful machine for http://gcov.php.net
up and running.
This new machine is running linux 64 bits, so expect a few differences in
the test results.I believe most things are ported from the old machine, including all
daemon's configurations.
I fired an experimental run of the cron job. Please help me by reporting
extensions that are not enabled, daemons that are misconfigured and why
(and
therefore some tests are failing or skiping), missing valgrind
suppressions,
and so on.Thanks to Nexcess for offering a new machine to replace the old one.
Nuno
Excellent work.
I see from the recent report that there are a LOT of similar warnings.
I'm guessing that those warnings, whilst they are generated on a linux
x64 box, would be the same for win32 (and anything else).What sort of policy is needed in addressing casting warnings like
this. I get a LOT of warnings about casting of doubles/floats to
ints/longs, along with the potential for potential data loss.How feasible is it to aim for a 100% warning free build? I'm not
meaning that we should suppress the warnings.--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea--
--
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
I would add:
2.1 fix the new ones
That's what I try to do using a delta between two revisions. At some
point these delta will be available online so anyone can fix them as
well, including the author of these new warnings.
That is an excellent point.
We have a Windows buildbox and I noticed gcov has started notifying
about broken builds..
We also have 5+ others servers (various BSD and Linux versions). Is
anyone working on a unified buildbot to run on these servers?
We also have the make test statistics on http://qa.php.net/reports/
by Oivier..
Would it be possible to coordinate all these efforts?
-Hannes
Here's my question - if I made some smaller commits here and there to
fix warnings in core, would that be accepted? I don't have time to do
sweeping changes, but fixing one file today, a couple the next day,
etc., is within my abilities (including making sure no regressions are
introduced, of course).
-- Gwynne
On Sat, Jul 23, 2011 at 18:54, Hannes Magnusson
hannes.magnusson@gmail.com wrote:
I would add:
2.1 fix the new ones
That's what I try to do using a delta between two revisions. At some
point these delta will be available online so anyone can fix them as
well, including the author of these new warnings.That is an excellent point.
We have a Windows buildbox and I noticed gcov has started notifying
about broken builds..We also have 5+ others servers (various BSD and Linux versions). Is
anyone working on a unified buildbot to run on these servers?We also have the
make teststatistics on http://qa.php.net/reports/
by Oivier..
Would it be possible to coordinate all these efforts?-Hannes
Here's my question - if I made some smaller commits here and there to
fix warnings in core, would that be accepted? I don't have time to do
sweeping changes, but fixing one file today, a couple the next day,
etc., is within my abilities (including making sure no regressions are
introduced, of course).
Why on earth would anyone complain about such commit from an
already-trusted-person-with-karma?
If you start flooding the commit list with one-liners, people will
probably complain.
But if you are willing to do the extensive work needed to fix several
warnings per commit..
I personally wouldn't commit such patch from 3rd party.
Reverting such commit from a person I trust however wouldn't come to mind.
Cursory review would be all I would do.
Can't speak for anyone else...
Fixing these sort of warnings in existing stable releases however IMO
causes more risk then necessary.
-Hannes
Here's my question - if I made some smaller commits here and there to
fix warnings in core, would that be accepted? I don't have time to do
sweeping changes, but fixing one file today, a couple the next day,
etc., is within my abilities (including making sure no regressions are
introduced, of course).
That's fine if it is done carefully. Note that the code needs to compile
on many different platforms, on many different compilers and versions of
compilers.
-Rasmus
On this subject, I've been looking into what produces the largest
warnings spam with a decent set of warnings turned on, and I'd like to
recommend this patch. I can't commit it myself (I don't have Zend
karma), nor would I care to without getting some opinion on it. The
patch is against 5.4, but should apply equally to trunk. No API is
changed, and no BC issues are created; it only adds a
forward-compatible optional declarator for the end of a
zend_function_entry struct. Obviously, the spammed warning in question
is "missing initializer", with respect to every function entry struct
in every extension, all of which simply use the {NULL, NULL, NULL}
from ext_skel. The intention is to provide this constant to protect
against future extensions of the structure. There are some other
structures which could also benefit from such an initializer
(smart_str and zend_fcall_info[_cache] come to mind).
Index: Zend/zend_API.h
--- Zend/zend_API.h (revision 313656)
+++ Zend/zend_API.h (working copy)
@@ -96,6 +96,8 @@
#define ZEND_NS_FALIAS(ns, name, alias, arg_info) ZEND_NS_FENTRY(ns,
name, ZEND_FN(alias), arg_info, 0)
#define ZEND_NS_DEP_FALIAS(ns, name, alias,
arg_info) ZEND_NS_FENTRY(ns, name, ZEND_FN(alias), arg_info,
ZEND_ACC_DEPRECATED)
+#define ZEND_FE_END { NULL, NULL, NULL, 0, 0 }
#define ZEND_ARG_INFO(pass_by_ref, name) { #name,
sizeof(#name)-1, NULL, 0, 0, 0, pass_by_ref},
#define ZEND_ARG_PASS_INFO(pass_by_ref) { NULL, 0, NULL, 0, 0,
0, pass_by_ref},
#define ZEND_ARG_OBJ_INFO(pass_by_ref, name, classname, allow_null) {
#name, sizeof(#name)-1, #classname, sizeof(#classname)-1, IS_OBJECT,
allow_null, pass_by_ref},
Index: main/php.h
--- main/php.h (revision 313656)
+++ main/php.h (working copy)
@@ -359,6 +359,7 @@
#define PHP_MALIAS ZEND_MALIAS
#define PHP_ABSTRACT_ME ZEND_ABSTRACT_ME
#define PHP_ME_MAPPING ZEND_ME_MAPPING
+#define PHP_FE_END ZEND_FE_END
#define PHP_MODULE_STARTUP_N ZEND_MODULE_STARTUP_N
#define PHP_MODULE_SHUTDOWN_N ZEND_MODULE_SHUTDOWN_N
-- Gwynne
Here's my question - if I made some smaller commits here and there to
fix warnings in core, would that be accepted? I don't have time to do
sweeping changes, but fixing one file today, a couple the next day,
etc., is within my abilities (including making sure no regressions are
introduced, of course).That's fine if it is done carefully. Note that the code needs to compile
on many different platforms, on many different compilers and versions of
compilers.-Rasmus
2011/7/25 Gwynne Raskind gwynne@darkrainfall.org:
On this subject, I've been looking into what produces the largest
warnings spam with a decent set of warnings turned on, and I'd like to
recommend this patch. I can't commit it myself (I don't have Zend
karma), nor would I care to without getting some opinion on it. The
patch is against 5.4, but should apply equally to trunk. No API is
changed, and no BC issues are created; it only adds a
forward-compatible optional declarator for the end of a
zend_function_entry struct. Obviously, the spammed warning in question
is "missing initializer", with respect to every function entry struct
in every extension, all of which simply use the {NULL, NULL, NULL}
from ext_skel. The intention is to provide this constant to protect
against future extensions of the structure. There are some other
structures which could also benefit from such an initializer
(smart_str and zend_fcall_info[_cache] come to mind).Index: Zend/zend_API.h
--- Zend/zend_API.h (revision 313656)
+++ Zend/zend_API.h (working copy)
@@ -96,6 +96,8 @@
#define ZEND_NS_FALIAS(ns, name, alias, arg_info) ZEND_NS_FENTRY(ns,
name, ZEND_FN(alias), arg_info, 0)
#define ZEND_NS_DEP_FALIAS(ns, name, alias,
arg_info) ZEND_NS_FENTRY(ns, name, ZEND_FN(alias), arg_info,
ZEND_ACC_DEPRECATED)+#define ZEND_FE_END { NULL, NULL, NULL, 0, 0 }
#define ZEND_ARG_INFO(pass_by_ref, name) { #name,
sizeof(#name)-1, NULL, 0, 0, 0, pass_by_ref},
#define ZEND_ARG_PASS_INFO(pass_by_ref) { NULL, 0, NULL, 0, 0,
0, pass_by_ref},
#define ZEND_ARG_OBJ_INFO(pass_by_ref, name, classname, allow_null) {
#name, sizeof(#name)-1, #classname, sizeof(#classname)-1, IS_OBJECT,
allow_null, pass_by_ref},
Index: main/php.h--- main/php.h (revision 313656)
+++ main/php.h (working copy)
@@ -359,6 +359,7 @@
#define PHP_MALIAS ZEND_MALIAS
#define PHP_ABSTRACT_ME ZEND_ABSTRACT_ME
#define PHP_ME_MAPPING ZEND_ME_MAPPING
+#define PHP_FE_END ZEND_FE_END#define PHP_MODULE_STARTUP_N ZEND_MODULE_STARTUP_N
#define PHP_MODULE_SHUTDOWN_N ZEND_MODULE_SHUTDOWN_N-- Gwynne
Here's my question - if I made some smaller commits here and there to
fix warnings in core, would that be accepted? I don't have time to do
sweeping changes, but fixing one file today, a couple the next day,
etc., is within my abilities (including making sure no regressions are
introduced, of course).That's fine if it is done carefully. Note that the code needs to compile
on many different platforms, on many different compilers and versions of
compilers.-Rasmus
You're right. Someone already had reported it. I'll work on adding on
all extensions.
--
Regards,
Felipe Pena
On this subject, I've been looking into what produces the largest
warnings spam with a decent set of warnings turned on, and I'd like to
recommend this patch. I can't commit it myself (I don't have Zend
karma), nor would I care to without getting some opinion on it. The
patch is against 5.4, but should apply equally to trunk. No API is
changed, and no BC issues are created; it only adds a
forward-compatible optional declarator for the end of a
zend_function_entry struct. Obviously, the spammed warning in question
is "missing initializer", with respect to every function entry struct
in every extension, all of which simply use the {NULL, NULL, NULL}
from ext_skel. The intention is to provide this constant to protect
against future extensions of the structure. There are some other
structures which could also benefit from such an initializer
(smart_str and zend_fcall_info[_cache] come to mind).Index: Zend/zend_API.h
--- Zend/zend_API.h (revision 313656)
+++ Zend/zend_API.h (working copy)
@@ -96,6 +96,8 @@
#define ZEND_NS_FALIAS(ns, name, alias, arg_info) ZEND_NS_FENTRY(ns,
name, ZEND_FN(alias), arg_info, 0)
#define ZEND_NS_DEP_FALIAS(ns, name, alias,
arg_info) ZEND_NS_FENTRY(ns, name, ZEND_FN(alias), arg_info,
ZEND_ACC_DEPRECATED)+#define ZEND_FE_END { NULL, NULL, NULL, 0, 0 }
#define ZEND_ARG_INFO(pass_by_ref, name) { #name,
sizeof(#name)-1, NULL, 0, 0, 0, pass_by_ref},
#define ZEND_ARG_PASS_INFO(pass_by_ref) { NULL, 0, NULL, 0, 0,
0, pass_by_ref},
#define ZEND_ARG_OBJ_INFO(pass_by_ref, name, classname, allow_null) {
#name, sizeof(#name)-1, #classname, sizeof(#classname)-1, IS_OBJECT,
allow_null, pass_by_ref},
Index: main/php.h--- main/php.h (revision 313656)
+++ main/php.h (working copy)
@@ -359,6 +359,7 @@
#define PHP_MALIAS ZEND_MALIAS
#define PHP_ABSTRACT_ME ZEND_ABSTRACT_ME
#define PHP_ME_MAPPING ZEND_ME_MAPPING
+#define PHP_FE_END ZEND_FE_END#define PHP_MODULE_STARTUP_N ZEND_MODULE_STARTUP_N
#define PHP_MODULE_SHUTDOWN_N ZEND_MODULE_SHUTDOWN_N-- Gwynne
Here's my question - if I made some smaller commits here and there to
fix warnings in core, would that be accepted? I don't have time to do
sweeping changes, but fixing one file today, a couple the next day,
etc., is within my abilities (including making sure no regressions are
introduced, of course).That's fine if it is done carefully. Note that the code needs to compile
on many different platforms, on many different compilers and versions of
compilers.
As there is also ZEND_NS_FE (I'm not seeing a PHP_NS_FE, due to no
namespaces in PHP ? I think), should there also be ZEND_NS_FE_END (and
for the purist in me PHP_NS_FE and PHP_NS_FE_END).
The only extension I've seen using ZEND_NS_FE is
https://github.com/lstrojny/functional-php.
Richard.
--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea
Hi,
We also have 5+ others servers (various BSD and Linux versions). Is
anyone working on a unified buildbot to run on these servers?
AFAIK, a buildbot was developed by Israel Ekpo
http://marc.info/?l=php-qa&m=126089572317391
But project semms to be dead (no news since 2009).
We also have the
make teststatistics on http://qa.php.net/reports/
by Oivier..
Would it be possible to coordinate all these efforts?
We can plug gcov results to qa.php.net/reports pretty easily.
I think we can plug this in php-gcov/trunk/cron/cron.php and send the XML
to the qa.php.net/reports/ interface.
If you can send me a sample, I can develop this tool.
Olivier Doucet
Given the variety of warnings that pop up in a PHP build (and don't
even start me on the list thrown up by Clang's static analyzer!), it's
a major undertaking to eliminate all the warnings, and it'll get ugly.
Exactly.
And given the nature of PHP, using several dozen bucketloads of
external libraries... it is isn't realistic to eliminate all random
[irrelevant] compiler warnings.
Couple of years ago I have vague memories of "homeland security" [usa]
project, and several projects after that, offering various analyzes of
php-src.
I believe security@php.net receives such reports automatically (they
had login credentials at least).
Removing compiler warnings is (in a project like PHP) generally not a
high priority, but again, if a trusted person commits such a patch.. I
highly doubt it would get reverted.
-Hannes
Thanks Nuno, great job!
Hi,
Thanks to Nexcess, we have a new wonderful machine for http://gcov.php.net
up and running.
This new machine is running linux 64 bits, so expect a few differences in
the test results.I believe most things are ported from the old machine, including all
daemon's configurations.
I fired an experimental run of the cron job. Please help me by reporting
extensions that are not enabled, daemons that are misconfigured and why
(and
therefore some tests are failing or skiping), missing valgrind
suppressions,
and so on.Thanks to Nexcess for offering a new machine to replace the old one.
Nuno
Excellent work.
I see from the recent report that there are a LOT of similar warnings.
I'm guessing that those warnings, whilst they are generated on a linux
x64 box, would be the same for win32 (and anything else).What sort of policy is needed in addressing casting warnings like
this. I get a LOT of warnings about casting of doubles/floats to
ints/longs, along with the potential for potential data loss.How feasible is it to aim for a 100% warning free build? I'm not
meaning that we should suppress the warnings.
I have vague memories from last year when a person tried to offer a
patch to initialize all structs "properly"..
It was semi-rejected, but if a person with karma to commit would take
it upon herself to commit such patch, I doubt it will be rejected.
A person without a proven repletion for karma to php-src posting such
patch posting it, is however massive work to review (read; major
work to review all edge cases) and will probably be ignored/rejected.
-Hannes