# new gcov.php.net machine is up - Thread: https://externals.io/message/54156 - Original archive: https://news-web.php.net/php.internals/54156 - Started by Nuno Lopes on 2011-07-23T16:03:16+00:00 - Messages: 16 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #54156 — Nuno Lopes — 2011-07-23T16:03:16+00:00 URL: https://externals.io/message/54156#54156 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 --- ## #54157 — Felipe Pena — 2011-07-23T16:13:47+00:00 URL: https://externals.io/message/54156#54157 · In reply to: #54156 2011/7/23 Nuno Lopes : > 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 --- ## #54158 — Antony Dovgal — 2011-07-23T16:16:20+00:00 URL: https://externals.io/message/54156#54158 · In reply to: #54156 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 --- ## #54164 — Richard Quadling — 2011-07-23T20:06:26+00:00 URL: https://externals.io/message/54156#54164 · In reply to: #54158 > Thanks Nuno, great job! > > > > […] 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 --- ## #54172 — Gwynne Raskind — 2011-07-23T22:36:35+00:00 URL: https://externals.io/message/54156#54172 · In reply to: #54164 In my experience, 100% warnings free is only practical in two cases: 1) When the project is built with that policy from day one. 2) 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 > > > […] > > 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 --- ## #54173 — Hannes Magnusson — 2011-07-23T22:41:29+00:00 URL: https://externals.io/message/54156#54173 · In reply to: #54164 > > > […] > > 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 --- ## #54174 — Pierre Joye — 2011-07-23T22:45:40+00:00 URL: https://externals.io/message/54156#54174 · In reply to: #54172 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 wrote: > In my experience, 100% warnings free is only practical in two cases: > > 1) When the project is built with that policy from day one. > 2) 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 > > > > […] > > -- > > > > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #54175 — Hannes Magnusson — 2011-07-23T22:47:47+00:00 URL: https://externals.io/message/54156#54175 · In reply to: #54172 > 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 --- ## #54176 — Hannes Magnusson — 2011-07-23T22:54:41+00:00 URL: https://externals.io/message/54156#54176 · In reply to: #54174 > 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 --- ## #54177 — Gwynne Raskind — 2011-07-23T23:07:48+00:00 URL: https://externals.io/message/54156#54177 · In reply to: #54176 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 wrote: > > > […] > > > 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 --- ## #54178 — Hannes Magnusson — 2011-07-23T23:21:59+00:00 URL: https://externals.io/message/54156#54178 · In reply to: #54177 > 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 --- ## #54179 — Rasmus Lerdorf — 2011-07-23T23:23:22+00:00 URL: https://externals.io/message/54156#54179 · In reply to: #54177 > 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 --- ## #54184 — Gwynne Raskind — 2011-07-25T04:34:44+00:00 URL: https://externals.io/message/54156#54184 · In reply to: #54179 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 > > > […] > > 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 --- ## #54187 — Felipe Pena — 2011-07-25T10:48:57+00:00 URL: https://externals.io/message/54156#54187 · In reply to: #54184 2011/7/25 Gwynne Raskind : > 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 > > > > > > […] > You're right. Someone already had reported it. I'll work on adding on all extensions. -- Regards, Felipe Pena --- ## #54207 — Richard Quadling — 2011-07-26T10:54:21+00:00 URL: https://externals.io/message/54156#54207 · In reply to: #54184 > 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 > > > > > > […] 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 --- ## #54219 — Olivier Doucet — 2011-07-27T12:51:52+00:00 URL: https://externals.io/message/54156#54219 · In reply to: #54176 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 test` statistics 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