Bug #101341 for Compress-Raw-Zlib: [PATCH] reduce compiler warnings and stderr noise

Tue Jan 06 07:25:42 2015 davem [...] iabyn.com - Ticket created

Subject:	[PATCH] reduce compiler warnings and stderr noise
Date:	Tue, 6 Jan 2015 12:25:32 +0000
To:	bug-Compress-Raw-Zlib [...] rt.cpan.org
From:	Dave Mitchell <davem [...] iabyn.com>

Dear maintainer of a dual-lived CPAN distribution: I'm currently attempting to get bleadperl to be warnings-clean; i.e. where (./Configure && make) 2>errs leaves no lines in 'errs'. Recently bleadperl made the -W options passed to the C compiler more fascist, and in addition we're trying to get blead to compile and run cleanly under clang's -fsanitize=undefined option. Due to that and other reasons, bleadperl's build is currently very noisy. Attached (hopefully) to this ticket is one or more patches that reduce the noise of your distribution when built as part of bleadperl. It would be great if they could make it into a new release of your distribution in time for incorporation into perl-5.22.0. Our timetable is: 2015-01-20 5.21.8 Contentious changes freeze 2015-02-20 5.21.9 User-visible changes freeze 2015-03-20 5.21.10 Full code freeze 2015-05-20 5.22.0 Stable release! so for example if a new release of your distribution included contentious features, then it would need to be merged into blead *prior* to the 20th of Jan. Thanks, Dave M. -- In my day, we used to edit the inodes by hand. With magnets.

Message body is not shown because sender requested not to inline it.

Wed Jan 07 15:23:24 2015 pmqs [...] cpan.org - Correspondence added

Thanks for the patch. The first is already in 2.068 (I uploaded that just before Christmas). Did bleed not automatically sync it? For the second change, I hold off. I really don't like making changes to 3rd party code unless I can convince the owner of the code to make the change. Otherwise it becomes a headache whenever it gets upgraded. If the change can be restructured using a << rather than a *, I suspect I will have an easier time getting it accepted.

Wed Jan 07 15:23:24 2015 The RT System itself - Status changed from 'new' to 'open'

Thu Jan 08 07:56:51 2015 davem [...] iabyn.com - Correspondence added

Subject:	Re: [rt.cpan.org #101341] [PATCH] reduce compiler warnings and stderr noise
Date:	Thu, 8 Jan 2015 12:56:30 +0000
To:	Paul Marquess via RT <bug-Compress-Raw-Zlib [...] rt.cpan.org>
From:	Dave Mitchell <davem [...] iabyn.com>

On Wed, Jan 07, 2015 at 03:23:24PM -0500, Paul Marquess via RT wrote: Show quoted text

> <URL: https://rt.cpan.org/Ticket/Display.html?id=101341 > > > Thanks for the patch. > > The first is already in 2.068 (I uploaded that just before Christmas). > Did bleed not automatically sync it?

No, that's just me being incompetent. I did most of this work before xmas, and forgot to rebase. Show quoted text

> For the second change, I hold off. I really don't like making changes to 3rd party code unless I can convince the owner of the code to make the change. Otherwise it becomes a headache whenever it gets upgraded. > > If the change can be restructured using a << rather than a *, I suspect > I will have an easier time getting it accepted.

Well, the diff below is functionally equivalent, but it includes an extra increment. I don't know whether that would be regarded more favourably, -#define RANK(f) (((f) << 1) - ((f) > 4 ? 9 : 0)) +#define RANK(f) ((((f)+1) << 1) - ((f) > 4 ? 9 : 0)) -- That he said that that that that is is is debatable, is debatable.

Mon Sep 14 15:27:32 2015 pmqs [...] cpan.org - Correspondence added

On Thu Jan 08 07:56:51 2015, davem@iabyn.com wrote: Show quoted text

> On Wed, Jan 07, 2015 at 03:23:24PM -0500, Paul Marquess via RT wrote:

> > <URL: https://rt.cpan.org/Ticket/Display.html?id=101341 > > > > > Thanks for the patch. > > > > The first is already in 2.068 (I uploaded that just before > > Christmas). > > Did bleed not automatically sync it?

> > No, that's just me being incompetent. I did most of this work before > xmas, > and forgot to rebase. >

> > For the second change, I hold off. I really don't like making changes > > to 3rd party code unless I can convince the owner of the code to make > > the change. Otherwise it becomes a headache whenever it gets > > upgraded. > > > > If the change can be restructured using a << rather than a *, I > > suspect > > I will have an easier time getting it accepted.

> > Well, the diff below is functionally equivalent, but it includes an > extra > increment. I don't know whether that would be regarded more > favourably, > > -#define RANK(f) (((f) << 1) - ((f) > 4 ? 9 : 0)) > +#define RANK(f) ((((f)+1) << 1) - ((f) > 4 ? 9 : 0))

Patched, thanks.

Mon Sep 14 15:27:48 2015 pmqs [...] cpan.org - Status changed from 'open' to 'patched'

Sun Dec 04 07:22:37 2016 pmqs [...] cpan.org - Fixed in 2.069 added

Sun Dec 04 07:22:37 2016 pmqs [...] cpan.org - Status changed from 'patched' to 'resolved'