Re: new gcov.php.net machine is up

From: Date: Sat, 23 Jul 2011 22:41:29 +0000
Subject: Re: new gcov.php.net machine is up
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-54173@lists.php.net to get a copy of this message
On Sat, Jul 23, 2011 at 22:06, Richard Quadling <rquadling@gmail.com> wrote: > On 23 July 2011 17:16, Antony Dovgal <tony@daylessday.org> wrote: >> Thanks Nuno, great job! >> >> On 07/23/2011 08:03 PM, Nuno Lopes wrote: >>> >>> 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

« previous php.internals (#54173) next »