Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:54173
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAKUjMCU6sUqmmH21AFhZcZr+09b9iMxJgjRCEhKqLLWOkM3CKQ@mail.gmail.com>
References: <EEC7B72B6296471D876EE88FC4A85623@pc07654>
	<4E2AF3D4.9070704@daylessday.org>
	<CAKUjMCU6sUqmmH21AFhZcZr+09b9iMxJgjRCEhKqLLWOkM3CKQ@mail.gmail.com>
Date: Sun, 24 Jul 2011 00:41:29 +0200
Message-ID: <CADNQb0UCQySE_iNns83R5bkJ=1k_+zLc3otKYcJYL32Wv7VPXQ@mail.gmail.com>
To: RQuadling@gmail.com
Cc: Antony Dovgal <tony@daylessday.org>, internals@lists.php.net
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] new gcov.php.net machine is up
From: hannes.magnusson@gmail.com (Hannes Magnusson)

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