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

On Sat, Jul 23, 2011 at 16:06, Richard Quadling <rquadl...@gmail.com> wrote:
> On 23 July 2011 17:16, Antony Dovgal <t...@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.
>
> --
> Richard Quadling
> Twitter : EE : Zend : PHPDoc
> @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to