Bleadperl v5.15.7-88-g7e4f045 breaks MLEHMANN/common-sense-3.4.tar.gz

[p5pRT]

Migrated from rt.perl.org#111500 (status was 'resolved')

Searchable as RT111500$

[p5pRT]

From @andk

Git bisect

---

commit 7e4f04509c6d4e8d2ed0e31eaf59004e5c930b39 Author​: Father Chrysostomos \sprout@​cpan\.org Date​: Thu Jan 26 20​:43​:17 2012 -0800

  Allow ${^WARNING_BITS} to turn off lexical warnings

Diagnostics

---

MLEHMANN/common-sense-3.4.tar.gz itself passes all tests but other modules that are using common​::sense start to emit warnings\, like MLEHMANN/JSON-XS-2.32.tar.gz\, MAKAMAKA/JSON-2.53.tar.gz\, DAGOLDEN/Metabase-Fact-0.021.tar.gz\, DAGOLDEN/Metabase-Client-Simple-0.008.tar.gz\, and DAGOLDEN/Test-Reporter-Transport-Metabase-1.999008.tar.gz

Sample report​: http​://www.cpantesters.org/cpan/report/55c6c0b2-5cbd-11e1-9287-70eb48abe0af

perl -V

---

Summary of my perl5 (revision 5 version 15 subversion 7) configuration​:   Commit id​: 7e4f04509c6d4e8d2ed0e31eaf59004e5c930b39   Platform​:   osname=linux\, osvers=3.2.0-1-amd64\, archname=x86_64-linux-ld   uname='linux k83 3.2.0-1-amd64 #1 smp sun feb 5 15​:17​:15 utc 2012 x86_64 gnulinux '   config_args='-Dprefix=/home/src/perl/repoperls/installed-perls/perl/v5.15.7-88-g7e4f045/127e -Dmyhostname=k83 -Dinstallusrbinperl=n -Uversiononly -Dusedevel -des -Ui_db -Uuseithreads -Duselongdouble -DDEBUGGING=-g'   hint=recommended\, useposix=true\, d_sigaction=define   useithreads=undef\, usemultiplicity=undef   useperlio=define\, d_sfio=undef\, uselargefiles=define\, usesocks=undef   use64bitint=define\, use64bitall=define\, uselongdouble=define   usemymalloc=n\, bincompat5005=undef   Compiler​:   cc='cc'\, ccflags ='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'\,   optimize='-O2 -g'\,   cppflags='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'   ccversion=''\, gccversion='4.6.2'\, gccosandvers=''   intsize=4\, longsize=8\, ptrsize=8\, doublesize=8\, byteorder=12345678   d_longlong=define\, longlongsize=8\, d_longdbl=define\, longdblsize=16   ivtype='long'\, ivsize=8\, nvtype='long double'\, nvsize=16\, Off_t='off_t'\, lseeksize=8   alignbytes=16\, prototype=define   Linker and Libraries​:   ld='cc'\, ldflags =' -fstack-protector -L/usr/local/lib'   libpth=/usr/local/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib /usr/lib   libs=-lnsl -ldb -ldl -lm -lcrypt -lutil -lc   perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc   libc=\, so=so\, useshrplib=false\, libperl=libperl.a   gnulibc_version='2.13'   Dynamic Linking​:   dlsrc=dl_dlopen.xs\, dlext=so\, d_dlsymun=undef\, ccdlflags='-Wl\,-E'   cccdlflags='-fPIC'\, lddlflags='-shared -O2 -g -L/usr/local/lib -fstack-protector'

Characteristics of this binary (from libperl)​:   Compile-time options​: HAS_TIMES PERLIO_LAYERS PERL_DONT_CREATE_GVSV   PERL_MALLOC_WRAP PERL_PRESERVE_IVUV PERL_USE_DEVEL   USE_64_BIT_ALL USE_64_BIT_INT USE_LARGE_FILES   USE_LOCALE USE_LOCALE_COLLATE USE_LOCALE_CTYPE   USE_LOCALE_NUMERIC USE_LONG_DOUBLE USE_PERLIO   USE_PERL_ATOF   Built under linux   Compiled at Mar 2 2012 22​:26​:34   @​INC​:   /home/src/perl/repoperls/installed-perls/perl/v5.15.7-88-g7e4f045/127e/lib/site_perl/5.15.7/x86_64-linux-ld   /home/src/perl/repoperls/installed-perls/perl/v5.15.7-88-g7e4f045/127e/lib/site_perl/5.15.7   /home/src/perl/repoperls/installed-perls/perl/v5.15.7-88-g7e4f045/127e/lib/5.15.7/x86_64-linux-ld   /home/src/perl/repoperls/installed-perls/perl/v5.15.7-88-g7e4f045/127e/lib/5.15.7   .

-- andreas

[p5pRT]

From @andk

SREZIC/Kwalify-1.21.tar.gz fails since v5.15.7-88-g7e4f045 when JSON is installed before it.

My testing did not discover this earlier because Kwalify is usually already built and tested before JSON and without JSON these tests are skipped.

-- andreas

[p5pRT]

From @cpansprout

On Fri Mar 02 15​:02​:36 2012\, andreas.koenig.7os6VVqR@​franz.ak.mind.de wrote​:

Git bisect ---------- commit 7e4f04509c6d4e8d2ed0e31eaf59004e5c930b39 Author​: Father Chrysostomos \sprout@​cpan\.org Date​: Thu Jan 26 20​:43​:17 2012 -0800

Allow $\{^WARNING\_BITS\} to turn off lexical warnings

Diagnostics ----------- MLEHMANN/common-sense-3.4.tar.gz itself passes all tests but other modules that are using common​::sense start to emit warnings\, like MLEHMANN/JSON-XS-2.32.tar.gz\, MAKAMAKA/JSON-2.53.tar.gz\, DAGOLDEN/Metabase-Fact-0.021.tar.gz\, DAGOLDEN/Metabase-Client-Simple-0.008.tar.gz\, and DAGOLDEN/Test-Reporter-Transport-Metabase-1.999008.tar.gz

Sample report​: http​://www.cpantesters.org/cpan/report/55c6c0b2-5cbd-11e1-9287- 70eb48abe0af

Attached is a patch that stops common​::sense from making assumptions about what value ${^WARNING_BITS} contains.

--

Father Chrysostomos

[p5pRT]

From @cpansprout

Inline Patch

```diff diff -rup common-sense-3.4-O3G94Q-orig/sense.pm.PL common-sense-3.4-O3G94Q/sense.pm.PL --- common-sense-3.4-O3G94Q-orig/sense.pm.PL 2011-01-13 22:16:50.000000000 -0800 +++ common-sense-3.4-O3G94Q/sense.pm.PL 2012-03-02 18:09:49.000000000 -0800 @@ -28,7 +28,7 @@ BEGIN { while () { if (/^IMPORT/) { print " # use warnings\n"; - printf " \${^WARNING_BITS} ^= \${^WARNING_BITS} ^ \"%s\";\n", + printf " \${^WARNING_BITS} = \"%s\";\n", join "", map "\\x$_", unpack "(H2)*", $WARN; print " # use strict, use utf8;\n"; printf " \$^H |= 0x%x;\n", $H; ```

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From bug-common-sense@rt.cpan.org

\<URL​: https://rt.cpan.org/Ticket/Display.html?id=75495 >

Hi!

You sent a possible bug report on or via rt.cpan.org. Please read this mail carefully if you want to be heard.

Most likely\, your report here will be ignored.

Please close the ticket again and sent it to the official contact address for the module in question (or send it to rt.cpan.org@​schmorp.de).

Why is this necessary?

rt.cpan.org has many deficiencies which makes it tedious and hard to use\, increasing the workload on the people who provide all the perl modules you probably appreciate (and that is really to be avoided - module authors should be able to invest all their time into improving their modules and not fighting with rt.cpan.org's bugs).

Still\, for some people\, rt.cpan.org is useful to have\, and some people even like it and really want to use it. That is fine\, too.

Unfortunately\, the designers of rt.cpan.org didn't make their "service" optional - you can neither opt-in nor opt-out of rt.cpan.org as a module author.

Just like a spammer\, rt.cpan.org forces its "service" (whether wanted or unwanted) on everybody. Just like a spammer\, they don't care for the people they actively hurt. Just like a spammer\, they don't don't care to fix these issues and make their "service" ethically acceptable.

You cannot even configure it to redirect tickets to somewhere else.

Unfortunately\, ignoring rt.cpan.org is not an option either​: for people reporting possible bugs there is no indication that their report will be ignored\, and for module authors it means they miss potentially vital bug reports such as yours (and of course it's a great impression if rt.cpan.org has lots of bug reports that are unanswered\, making a module look unmaintained when in fact the opposite might be true).

I am sorry that this wasted a bit of your time\, but please understand that I am just as much a victim as you are - the problem is the unethical stance of the rt.cpan.org providers who force their "service" on everybody.

Please redirect your bug report as stated in the beginning of this mail\, and please consider petitioning the rt.cpan.org providers to stop their unethical behaviour and allow opt-in\, opt-out\, or some redirect option.

Thanks a lot\, Marc Lehmann \rt\.cpan\.org@&#8203;schmorp\.de

[p5pRT]

From @ap

* Marc Lehmann via RT \bug\-common\-sense@&#8203;rt\.cpan\.org [2012-03-03 07​:15]​:

\<URL​: https://rt.cpan.org/Ticket/Display.html?id=75495 >

Hi!

Hello Marc!

You sent a possible bug report on or via rt.cpan.org. Please read this mail carefully if you want to be heard.

Please read my response carefully in turn so as to avoid this discussion entirely in the future.

Most likely\, your report here will be ignored.

Please close the ticket again and sent it to the official contact address for the module in question (or send it to rt.cpan.org@​schmorp.de).

Why is this necessary?

rt.cpan.org has many deficiencies which makes it tedious and hard to use\, increasing the workload on the people who provide all the perl modules you probably appreciate (and that is really to be avoided - module authors should be able to invest all their time into improving their modules and not fighting with rt.cpan.org's bugs).

Still\, for some people\, rt.cpan.org is useful to have\, and some people even like it and really want to use it. That is fine\, too.

Unfortunately\, the designers of rt.cpan.org didn't make their "service" optional - you can neither opt-in nor opt-out of rt.cpan.org as a module author.

If you are going to lecture users with insufferably worded autogenerated responses\, you would do well to do your homework first and not parade your ignorance around.

Just like a spammer\, rt.cpan.org forces its "service" (whether wanted or unwanted) on everybody. Just like a spammer\, they don't care for the people they actively hurt. Just like a spammer\, they don't don't care to fix these issues and make their "service" ethically acceptable.

You cannot even configure it to redirect tickets to somewhere else.

No\, but the CPAN Meta Spec defines a `bugtracker` sub-key under the optional `resources` key which allows you to define which bugtracker you want to receive reports on\, both web-based and email-based.

Cf. \https://metacpan.org/module/CPAN::Meta::Spec#resources

Sites like search.cpan.org have long respected this data and they will modify the bugtracker link they present to users according to your stated preference.

Making this out to be a question of ethics and equating it to spam is overblown melodrama unbecoming of anyone beyond their teenage years.

Unfortunately\, ignoring rt.cpan.org is not an option either​: for people reporting possible bugs there is no indication that their report will be ignored\, and for module authors it means they miss potentially vital bug reports such as yours (and of course it's a great impression if rt.cpan.org has lots of bug reports that are unanswered\, making a module look unmaintained when in fact the opposite might be true).

I am sorry that this wasted a bit of your time\, but please understand that I am just as much a victim as you are - the problem is the unethical stance of the rt.cpan.org providers who force their "service" on everybody.

Since you have your users’ valuable wasted time at heart I am sure that you will at once upload an updated version of all your modules which redirect your users to a bugtracker of your choice and to your tastes\, and that you will then make a final one-time effort to move any lost CPAN RT tickets to this new and appropriate location.

Please redirect your bug report as stated in the beginning of this mail\, and please consider petitioning the rt.cpan.org providers to stop their unethical behaviour and allow opt-in\, opt-out\, or some redirect option.

Thanks a lot\, Marc Lehmann \rt\.cpan\.org@&#8203;schmorp\.de

You are welcome.

Regards\, -- Aristotle Pagaltzis // \<http​://plasmasturm.org/>

[p5pRT]

From @nwc10

Right\, I'm going to call *you* out on this one.

Aristotle\, if you want to make a point\, don't be so damn patronising.

It's not needed. You know what's going to happen next. It's almost like you wanted to start a flame war and look clever in the process.

Yes\, that's why I'm being this blunt.

On Sat\, Mar 03\, 2012 at 05​:39​:08PM +0100\, Aristotle Pagaltzis wrote​:

* Marc Lehmann via RT \bug\-common\-sense@&#8203;rt\.cpan\.org [2012-03-03 07​:15]​:

Unfortunately\, the designers of rt.cpan.org didn't make their "service" optional - you can neither opt-in nor opt-out of rt.cpan.org as a module author.

As Aristotle notes\, this is not true now. CPAN Meta Spec defines "bugtracker" and (I think) setting this to point elsewhere does kill the rt.cpan.org queues.

If not\, there *is* some way to do it *these days*\, as there's no rt.cpan.org queue for App​::Ack\, a distribution on CPAN\, and rt.cpan.org won't let me file bugs for it there.

However\, I don't think it used to be easy to close down rt.cpan.org queues\, so I'd guess that Marc's autoresponder dates from then.

And\, specifically\, as well as expressing his opinion\, it *also* explains how to report the bug so that it doesn't get lost. It's not a "go away" message\, it's a "you need to do this instead"

This is my second fault​:

Since you have your users' valuable wasted time at heart I am sure that you will at once upload an updated version of all your modules which redirect your users to a bugtracker of your choice and to your tastes\, and that you will then make a final one-time effort to move any lost CPAN RT tickets to this new and appropriate location.

Everyone seems to forget that software on CPAN is a free gift\, as is\, in the hope that it might be useful.

Somehow end users seem to think this means that the author is now obliged to offer support and bugfixing in a timely fashion\, and pretty much infinite help indefinitely.

The users' valuable time is *nowhere near* as important as the original author's time. There's 1 author\, and multiple users.

If rt.cpan.org doesn't serve the author's purpose\, that's a valid state of affairs.

Nicholas Clark

[p5pRT]

From @ap

* Nicholas Clark \nick@&#8203;ccl4\.org [2012-03-03 18​:10]​:

Aristotle\, if you want to make a point\, don't be so damn patronising.

:-) That was my point.

It's not needed. You know what's going to happen next. It's almost like you wanted to start a flame war and look clever in the process.

Beyond making a point\, I was also intentionally excessive in hopes of disinviting unnecessary conversation. My point is made.

Yes\, that's why I'm being this blunt.

No worries about offending me.

If not\, there *is* some way to do it *these days*\, as there's no rt.cpan.org queue for App​::Ack\, a distribution on CPAN\, and rt.cpan.org won't let me file bugs for it there.

Yes\, my own distributions don’t have RT queues either\, effected by the `bugtracker` META key.

And\, specifically\, as well as expressing his opinion\, it *also* explains how to report the bug so that it doesn't get lost. It's not a "go away" message\, it's a "you need to do this instead"

This is my second fault​:

Since you have your users' valuable wasted time at heart I am sure that you will at once upload an updated version of all your modules which redirect your users to a bugtracker of your choice and to your tastes\, and that you will then make a final one-time effort to move any lost CPAN RT tickets to this new and appropriate location.

Everyone seems to forget that software on CPAN is a free gift\, as is\, in the hope that it might be useful.

Somehow end users seem to think this means that the author is now obliged to offer support and bugfixing in a timely fashion\, and pretty much infinite help indefinitely.

The users' valuable time is *nowhere near* as important as the original author's time. There's 1 author\, and multiple users.

If rt.cpan.org doesn't serve the author's purpose\, that's a valid state of affairs.

I agree with all of that. I do not in fact expect Marc to go to the trouble (which may well be unreasonably much work in his case). I take no issue at all with the desires he expressed either. If he didn’t also disparage a freely provided service and the ethics of the volunteers who maintain it\, for what was actually a failure of trivial diligence on his own part\, my reply would have been a three-line offlist mail with a note and the link.

Regards\, -- Aristotle Pagaltzis // \<http​://plasmasturm.org/>

[p5pRT]

From schmorp@schmorp.de

On Sat\, Mar 03\, 2012 at 05​:39​:08PM +0100\, Aristotle Pagaltzis \pagaltzis@&#8203;gmx\.de wrote​:

* Marc Lehmann via RT \bug\-common\-sense@&#8203;rt\.cpan\.org [2012-03-03 07​:15]​:

\<URL​: https://rt.cpan.org/Ticket/Display.html?id=75495 >

Hi!

Hello Marc!

Please note that I sent you a private reply\, to give you a chance to apologise for your needless insults. You should really think twice before dragging such things into public.

To the others who unfortunately suffered from his needless verbal insults\, let me point out that my auto-reply is about rt.cpan.org\, not search.cpan.org or any other site\, and there is (to my knowledge) no way to influence rt.cpan.org via meta files in any way. I really do check this once a year\, and this was confirmed to me by an rt.cpan.org admin.

It seems Aristotle simply confused rt.cpan.org (which my mail was about) with search.cpan.org (which his mail seems to be about about).

Mistakes can always happen\, but this underscores the importance of staying civil at least until you are sure you know what you are talking about...

PS​: I don't know what it is that makes random people spew out personal and unfounded insults against me on this list\, but I really think this list is not the place for this kind of behaviour\, and I admit I do start to feel harassed by that. So please\, if you have a problem with me\, try to solve it like you are a grown up. Insulting me on this list\, or even spreading outright lies\, such as Rocco has done\, will not solve any problem\, and will only force me to expose these. What you need to do is state facts and logical arguments based on them\, that's the only thing that works with me. Really.

--   The choice of a Deliantra\, the free code+content MORPG   -----==- _GNU_ http​://www.deliantra.net   ----==-- _ generation   ---==---(_)__ __ ____ __ Marc Lehmann   --==---/ / _ \/ // /\ \/ / schmorp@​schmorp.de   -=====/_/_//_/\_\,_/ /_/\_\

[p5pRT]

From schmorp@schmorp.de

On Sat\, Mar 03\, 2012 at 05​:07​:38PM +0000\, Nicholas Clark \nick@&#8203;ccl4\.org wrote​:

Right\, I'm going to call *you* out on this one.

I am confused\, you call me out in what way?

On Sat\, Mar 03\, 2012 at 05​:39​:08PM +0100\, Aristotle Pagaltzis wrote​:

* Marc Lehmann via RT \bug\-common\-sense@&#8203;rt\.cpan\.org [2012-03-03 07​:15]​:

As Aristotle notes\, this is not true now. CPAN Meta Spec defines "bugtracker" and (I think) setting this to point elsewhere does kill the rt.cpan.org queues.

You think. I get a mail per year that tells me the same. It was never true in the past\, and it really is not my job to run after what I consider an immoral spamming service frustrating module users and maintainers alike.

Regardless\, do you have a source? That would really be great.

However\, I don't think it used to be easy to close down rt.cpan.org

I was told by an admin it was impossible. Repeatedly.

But in any case\, this doesn't solve the real problem. Even if it were possible to kill queues via the meta file\, it forces productive authors with many modules (and there are some wiht a lot more than me) to make dummy releases for all of them.

Dummy releases is a disservice to users\, and an unneeded burden on maintainers.

If rt.cpan.org gets such a prominent role on some sites (such as\, apparently\, search.cpan.org\, a site I do not use for my bug reporting needs)\, then it also has the burden of deflecting this. It mustn't be the sole responsibility of module authors to work around every new service that some website thinks should be advertised for all perl modules.

Everyone seems to forget that software on CPAN is a free gift\, as is\, in the hope that it might be useful.

Somehow end users seem to think this means that the author is now obliged to offer support and bugfixing in a timely fashion\, and pretty much infinite help indefinitely.

The users' valuable time is *nowhere near* as important as the original author's time. There's 1 author\, and multiple users.

If rt.cpan.org doesn't serve the author's purpose\, that's a valid state of affairs.

No disagreement here. And I certainly believe (whether true or not...) that I invest a lot of time into making the little software I actually publish well-documented and useful to others\, and usually give support within 24 hours. I respect disagreeing opinions on this and other things\, but reserve the right to have my own ideas\, no matter how weird they seem some.

And in the past\, I always thought this as being the strength of the perl community as a whole. I can't help but feel that this is slowly changing into a "you have to think\, act and be like the mainstream\, otherwise we don't want you on CPAN"\, and no matter what\, I will not follow this trend.

--   The choice of a Deliantra\, the free code+content MORPG   -----==- _GNU_ http​://www.deliantra.net   ----==-- _ generation   ---==---(_)__ __ ____ __ Marc Lehmann   --==---/ / _ \/ // /\ \/ / schmorp@​schmorp.de   -=====/_/_//_/\_\,_/ /_/\_\

[p5pRT]

From @ap

* Marc Lehmann \schmorp@&#8203;schmorp\.de [2012-03-03 23​:20]​:

It seems Aristotle simply confused rt.cpan.org (which my mail was about) with search.cpan.org (which his mail seems to be about about).

There was no confusion on my part.

[p5pRT]

From @kentfredric

On 4 March 2012 06​:07\, Nicholas Clark \nick@&#8203;ccl4\.org wrote​:

And\, specifically\, as well as expressing his opinion\, it *also* explains how to report the bug so that it doesn't get lost. It's not a "go away" message\, it's a "you need to do this instead"

I'd like to constructively point out\, that while this is the case\, for some reason the formatting/wording of it seems distracting.

I would have myself reported this bug myself\, however\, a few things stopped me.

In short\, the easiest change I feel would be helpful in increasing the constructiveness of bugs reported to you is a restructure of that automated reply to be more goal oriented\, prioritising explaining how to correctly file bugs over explaining your philosophy.

You might think the existing segment would be enough\, but strangely\, it wasn't when I saw it last on another bug​:

Hi!

You sent a possible bug report on or via rt.cpan.org. Please read this mail carefully if you want to be heard.

Most likely\, your report will be ignored.

Please close the ticket again and sent it to the official contact address for the module in question (or send it to rt.cpan.org@​schmorp.de).

Why is this necessary?

For some peculiar reason\, this parses as :

Hi

Your report will be ignored

tl;dr

Which while the original message was probably well intended\, the actual effect on some people tends to be no different than you had said

Hi

You seem to have filed a bug.

I hate you.

Which I'm guessing you don't mean to say =)

And even when you read slightly more carefully\, you find the phrase

"send it to the official contact address for the module in question"

Which simply raises the question "What is the official contact address for this module?"

I looked\, I saw no such stated "official address" in the dist itself\, and this statement eludes to the fact that one such official address has been stated\, and I was simply unable to find it.

I would suggest a simpler directive :

Hi

Please send bugs reports to : \@​schmorp.de

Sorry for the inconvenience\,

Marc.

P.s. I don't like RT and don't wish to use RT \, so when you're done here\, please just close your own bug =)

\

There are other things that can be done to make things more sensible for users who wish to file bugs\, but this would be by far the easiest change to make\, and in my mind\, the most effective at reducing the emotional reaction people may currently feel when greeted with your responder\, which I can only really describe as "Soul Sucking".

I generally file bugs because I believe that doing so provides some utility to the author and other users of the software.

I don't file bugs out of an expectation that the bug will be fixed\, just out of intent to let the author know that their code is not functioning as they had possibly intended\, and additionally\, in the case of a bug tracker\, to allow other users to know they're not the first to see the bug\, and to eliminate their desire to file the same bug again to an author \, not knowing its already been filed.

I sincerely hope this response provides some useful utility\, hopefully long term\, and I would not have responded at all otherwise.

--

Kent

perl -e  "print substr( \"edrgmaM  SPA NOcomil.ic\\@​tfrken\"\, \$_ * 3\, 3 ) for ( 9\,8\,0\,7\,1\,6\,5\,4\,3\,2 );"

[p5pRT]

From @andk

I sent my original bugreport to perlbug@​perl.org. Erroneously I sent a CC to mlehmann@​perl.org. Sorry for the glitch\, I hope I got at least one of the addresses in "To​:" correct this time.

If you have not seen it\, please see the ticket\, especially the first answer from Father Chrisostomos with a patch at https://rt-archive.perl.org/perl5/Public/Bug/Display.html?id=111500

I'm interested in hearing what you think about it.

-------------------- Start of forwarded message -------------------- From​: andreas.koenig.7os6VVqR@​franz.ak.mind.de (Andreas J. Koenig) To​: perlbug@​perl.org Cc​: sprout@​cpan.org\, mlehmann@​perl.org Subject​: Bleadperl v5.15.7-88-g7e4f045 breaks MLEHMANN/common-sense-3.4.tar.gz Date​: Fri\, 02 Mar 2012 23​:52​:55 +0100 Message-ID​: \87zkby1upk\.fsf@&#8203;franz\.ak\.mind\.de User-Agent​: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) Lines​: 73 Xref​: k75 sent​:6136

Git bisect

---

commit 7e4f04509c6d4e8d2ed0e31eaf59004e5c930b39 Author​: Father Chrysostomos \sprout@&#8203;cpan\.org Date​: Thu Jan 26 20​:43​:17 2012 -0800

  Allow ${^WARNING_BITS} to turn off lexical warnings

Diagnostics

---

MLEHMANN/common-sense-3.4.tar.gz itself passes all tests but other modules that are using common​::sense start to emit warnings\, like MLEHMANN/JSON-XS-2.32.tar.gz\, MAKAMAKA/JSON-2.53.tar.gz\, DAGOLDEN/Metabase-Fact-0.021.tar.gz\, DAGOLDEN/Metabase-Client-Simple-0.008.tar.gz\, and DAGOLDEN/Test-Reporter-Transport-Metabase-1.999008.tar.gz

Sample report​: http​://www.cpantesters.org/cpan/report/55c6c0b2-5cbd-11e1-9287-70eb48abe0af

perl -V

---

Summary of my perl5 (revision 5 version 15 subversion 7) configuration​:   Commit id​: 7e4f04509c6d4e8d2ed0e31eaf59004e5c930b39   Platform​:   osname=linux\, osvers=3.2.0-1-amd64\, archname=x86_64-linux-ld   uname='linux k83 3.2.0-1-amd64 #1 smp sun feb 5 15​:17​:15 utc 2012 x86_64 gnulinux '   config_args='-Dprefix=/home/src/perl/repoperls/installed-perls/perl/v5.15.7-88-g7e4f045/127e -Dmyhostname=k83 -Dinstallusrbinperl=n -Uversiononly -Dusedevel -des -Ui_db -Uuseithreads -Duselongdouble -DDEBUGGING=-g'   hint=recommended\, useposix=true\, d_sigaction=define   useithreads=undef\, usemultiplicity=undef   useperlio=define\, d_sfio=undef\, uselargefiles=define\, usesocks=undef   use64bitint=define\, use64bitall=define\, uselongdouble=define   usemymalloc=n\, bincompat5005=undef   Compiler​:   cc='cc'\, ccflags ='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'\,   optimize='-O2 -g'\,   cppflags='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'   ccversion=''\, gccversion='4.6.2'\, gccosandvers=''   intsize=4\, longsize=8\, ptrsize=8\, doublesize=8\, byteorder=12345678   d_longlong=define\, longlongsize=8\, d_longdbl=define\, longdblsize=16   ivtype='long'\, ivsize=8\, nvtype='long double'\, nvsize=16\, Off_t='off_t'\, lseeksize=8   alignbytes=16\, prototype=define   Linker and Libraries​:   ld='cc'\, ldflags =' -fstack-protector -L/usr/local/lib'   libpth=/usr/local/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib /usr/lib   libs=-lnsl -ldb -ldl -lm -lcrypt -lutil -lc   perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc   libc=\, so=so\, useshrplib=false\, libperl=libperl.a   gnulibc_version='2.13'   Dynamic Linking​:   dlsrc=dl_dlopen.xs\, dlext=so\, d_dlsymun=undef\, ccdlflags='-Wl\,-E'   cccdlflags='-fPIC'\, lddlflags='-shared -O2 -g -L/usr/local/lib -fstack-protector'

Characteristics of this binary (from libperl)​:   Compile-time options​: HAS_TIMES PERLIO_LAYERS PERL_DONT_CREATE_GVSV   PERL_MALLOC_WRAP PERL_PRESERVE_IVUV PERL_USE_DEVEL   USE_64_BIT_ALL USE_64_BIT_INT USE_LARGE_FILES   USE_LOCALE USE_LOCALE_COLLATE USE_LOCALE_CTYPE   USE_LOCALE_NUMERIC USE_LONG_DOUBLE USE_PERLIO   USE_PERL_ATOF   Built under linux   Compiled at Mar 2 2012 22​:26​:34   @​INC​:   /home/src/perl/repoperls/installed-perls/perl/v5.15.7-88-g7e4f045/127e/lib/site_perl/5.15.7/x86_64-linux-ld   /home/src/perl/repoperls/installed-perls/perl/v5.15.7-88-g7e4f045/127e/lib/site_perl/5.15.7   /home/src/perl/repoperls/installed-perls/perl/v5.15.7-88-g7e4f045/127e/lib/5.15.7/x86_64-linux-ld   /home/src/perl/repoperls/installed-perls/perl/v5.15.7-88-g7e4f045/127e/lib/5.15.7   .

-- andreas

-------------------- End of forwarded message --------------------

-- andreas

[p5pRT]

From schmorp@schmorp.de

On Sun\, Mar 04\, 2012 at 01​:57​:41PM +1300\, Kent Fredric \kentfredric@&#8203;gmail\.com wrote​:

I'd like to constructively point out\, that while this is the case\, for some reason the formatting/wording of it seems distracting.

I would have myself reported this bug myself\, however\, a few things stopped me.

In short\, the easiest change I feel would be helpful in increasing the constructiveness of bugs reported to you is a restructure of that automated reply to be more goal oriented\, prioritising explaining how to correctly file bugs over explaining your philosophy.

Well\, it's a trade-off. In the beginning\, the message just asked people to report bugs by mail.

It got me an enourmous number of religiously-motivated emails on why I don't use rt.cpan.org\, that I should use rt.cpan.org etc. etc.

After adding my rationale\, this stopped.

That *might* be because now everybody just didn't bother anymore\, but I still get a lot of valid bug emails\, and once in a while\, when I clean up bugs\, I recognise them on rt.cpan.org\, so it seems this is worded much better.

I simply don't have the time nor the wish to deal with religious debates\, I want to do software. I just wish trolls would leave me and my honest users alone. I never have a problem with actual users\, it's only rival module authors or some would-be-perl gods who think they have to force an http tracker on everybody\, or who think e-mail is not professional or acceptable enough to use for reporting bugs.

I deliberately put the reporting address near the very top of my response (it's in the third\, very short\, paragraph).

In fact\, I designed my responder so people can report bugs without reading any rationale at all\, they can just ignore the rest of the mail.

I would love if rt.cpan.org was more user-friendly and let me tell people in some other way that they should report bugs elsewhere.

Given that rt.cpan.org is pushed by some sites as the de-facto standard\, just closing down queues\, while an improvement\, is wrong\, because I know amny users go directly to rt.cpan.org.

To me\, rt.cpan.org is just not acting in good faith - it gets the status of semi-official bug tracking site\, but never lives up to it\, but instead is designed to put considerable pressure on module authors to use it\, or suffer from bad service for users.

That the site uses comemrcial advertising doesn't help. I don't want to promote a service I don't use\, but rt.cpan.org gives me little chance.

For some peculiar reason\, this parses as :

Which while the original message was probably well intended\, the actual effect on some people tends to be no different than you had said

I didn't expect that people don't even read three sentences. I will change that. The original intent is to clearly tell people that their bug report *will* likely be ignored\, because otherwise\, people might think\, well\, otherwise.

Note\, however\, that you are the absolute exception. The amount of tickets on rt.cpan.org extremely closely matches the amount of mail I get\, so almost everybody gets the message.

In any case\, ti reads like this now​:

  You sent a possible bug report on or via rt.cpan.org. Please read this   mail carefully if you want to be heard.

  Please send your bug report it to the official contact address for the   module in question (or send it to rt.cpan.org@​schmorp.de\, that's fine as   well).

I hate you.

Which I'm guessing you don't mean to say =)

No\, if I want to say that\, I would have simply written that\, for sure.

And even when you read slightly more carefully\, you find the phrase

"send it to the official contact address for the module in question"

Which simply raises the question "What is the official contact address for this module?"

Since my manpages all have an author section\, and some have further support option\, and all these modules are author-supported\,. which is what by far most of the modules on cpan are\, all you need to do is scroll to the end\, or search for an e-mail address.

See\, the problem is rt.cpan.org and possibly search.cpan.org\, because they changed the default mode of operations (author-supported software) to an rt.cpan.org enforced system.

There are many (probably hudnreds) of "queues" on rt.cpan.org which have reported and ignroed bugs\, most likely\, because the authors were not prepared with rt.cpan.org being forced on them.

I looked\, I saw no such stated "official address" in the dist itself\,

I am sorry\, but you didn't look very hard at all then. All you need to do is to look at the manpage of the module in question\, they *all* have my contact address.

The e-mail reply also lists another contatc address\, so there is no excuse to not finding one address to send to.

and this statement eludes to the fact that one such official address has been stated\, and I was simply unable to find it.

That frankly sounds to me as if we need some kind of internet drivers license\, or maybe a developers drivers license. Not everything is an http url\, even though rt.cpan.org seems to make us believe so.

Please send bugs reports to : \@​schmorp.de

I would still prefer the official contatc address\, even if most of them just lead to me.

I changed it to this now​:

  You sent a possible bug report on or via rt.cpan.org.

  Sorry for the inconvenience.

  Please send your bug report it to the official contact address for the   module in question (or send it to rt.cpan.org@​schmorp.de\, that's fine as   well).

P.s. I don't like RT and don't wish to use RT \, so when you're done here\, please just close your own bug =)

I found out that rt.cpan.org doesn't even let you close your own bug anymore\, btw.\, something I forgot to change in my response as well.

If rt.cpan.org has you\, it doesn't give you up.

change to make\, and in my mind\, the most effective at reducing the emotional reaction people may currently feel when greeted with your responder\, which I can only really describe as "Soul Sucking".

Well\, keep in mind that the only evidence for that is you right now\, while there are hundreds of people who simply reported the bug to me via e-mail.

I generally file bugs because I believe that doing so provides some utility to the author and other users of the software.

It certainly does\, overall\, but most bug reports are simply bogus\, or support requests\, so not every bug report is a bug report\, and not every bug report is useful. In fact\, most are a burden.

Could well be that all your bug reports are useful\, or at leats the majority - but that is already a major accomplishment :)

I don't file bugs out of an expectation that the bug will be fixed\, just out of intent to let the author know that their code is not functioning as they had possibly intended\, and additionally\, in the case of a bug tracker\, to allow other users to know they're not the first to see the bug\, and to eliminate their desire to file the same bug again to an author \, not knowing its already been filed.

That's useful to know\, even when it isn't a bug - it could warrant more mention in the documentation for example.

I sincerely hope this response provides some useful utility\, hopefully long term\, and I would not have responded at all otherwise.

Maybe - it did lead me to change my response\, which is all you suggested.

--   The choice of a Deliantra\, the free code+content MORPG   -----==- _GNU_ http​://www.deliantra.net   ----==-- _ generation   ---==---(_)__ __ ____ __ Marc Lehmann   --==---/ / _ \/ // /\ \/ / schmorp@​schmorp.de   -=====/_/_//_/\_\,_/ /_/\_\

[p5pRT]

From schmorp@schmorp.de

On Sun\, Mar 04\, 2012 at 08​:35​:15AM +0100\, "Andreas J. Koenig" \andreas\.koenig\.7os6VVqR@&#8203;franz\.ak\.mind\.de wrote​:

If you have not seen it\, please see the ticket\, especially the first answer from Father Chrisostomos with a patch at https://rt-archive.perl.org/perl5/Public/Bug/Display.html?id=111500

I'm interested in hearing what you think about it.

Well\, thanks a lot. Pity that the code was designed to actually do the right thing\, and I feel perl 5.15 is the culprit here by considerably changing how the warning system works.

I would like to understand it though​: the current code turns off all warnings bits except the ones the user asked for.

The new code would leave warning bits on.

Use common​::sense is supposed to set warnigns to a predefined set\, not to disable some and enable others.

So it seems to me that the warning bits are no longer that\, warning bits\, but either non-warning bits or are being abused for something else\, which would be bad design.

I don't know what 5.15 actually does\, but if turning off warning bits causes errornous warnings\, then I would expect this to be treated as a bug in perl.

Now\, either I don't understand whats going on (then I would like to learn)\, or maybe the new style means this is what's going to be done in 5.15\, which means I'll simply have to make it work somehow - common​::sense uses undocumented bits\, so perl can change them at will.

However\, if I am right and 5.15 abuses the warning bits for something else\, I would ask the p5p'ers to reconsider their design to something more sane.

--   The choice of a Deliantra\, the free code+content MORPG   -----==- _GNU_ http​://www.deliantra.net   ----==-- _ generation   ---==---(_)__ __ ____ __ Marc Lehmann   --==---/ / _ \/ // /\ \/ / schmorp@​schmorp.de   -=====/_/_//_/\_\,_/ /_/\_\

[p5pRT]

From @ap

* Marc Lehmann \schmorp@&#8203;schmorp\.de [2012-03-04 09​:20]​:

See\, the problem is rt.cpan.org and possibly search.cpan.org\, because they changed the default mode of operations (author-supported software) to an rt.cpan.org enforced system.

The world is bigger than Perl\, rt.cpan.org tried to offer something to authors that users were already coming to expect from elsewhere. It did not change anything\, at most it may have sped things along.

If you want to keep doing it the way it used to be done\, that’s entirely fine. You just have to realise that users will come to you with other expectations\, so you if you want things to work smoothly you will need to tell them very explicitly that you prefer something different from what they assume.

I am sorry\, but you didn't look very hard at all then. All you need to do is to look at the manpage of the module in question\, they *all* have my contact address.

The e-mail reply also lists another contatc address\, so there is no excuse to not finding one address to send to.

Finding the address is not the problem. I found it\, and I am certain Kent saw it too. But *every* module lists an author email in the AUTHOR section. And for most of them\, that does *not* mean bugs be reported by direct mail. So the email address you list there will not be understood the way you want it to be understood. If you do not explicitly tell your users that you want bug reports by mail\, they will not realise.

some would-be-perl gods who think they have to force an http tracker on everybody\, or who think e-mail is not professional or acceptable enough to use for reporting bugs.

FWIW [to everyone else]\, Marc accused me of this in private mail – when it was nowhere to be found in any of my mails. What *is* to be found is that I said it’s fine for him to have any preference for bugreporting avenues he likes… I do not doubt that he gets an enourmous number of religiously-motivated email regardless\, but given this perspective\, his perception of their magnitude and fervour may not be accurate.

Regards\, -- Aristotle Pagaltzis // \<http​://plasmasturm.org/>

[p5pRT]

From @cpansprout

On Sun Mar 04 00​:26​:42 2012\, schmorp@​schmorp.de wrote​:

On Sun\, Mar 04\, 2012 at 08​:35​:15AM +0100\, "Andreas J. Koenig" \andreas\.koenig\.7os6VVqR@&#8203;franz\.ak\.mind\.de wrote​:

If you have not seen it\, please see the ticket\, especially the first answer from Father Chrisostomos with a patch at https://rt-archive.perl.org/perl5/Public/Bug/Display.html?id=111500

I'm interested in hearing what you think about it.

Well\, thanks a lot. Pity that the code was designed to actually do the right thing\, and I feel perl 5.15 is the culprit here by considerably changing how the warning system works.

I would like to understand it though​: the current code turns off all warnings bits except the ones the user asked for.

Maybe I am misunderstanding something. It sounds as though you are saying that

  use warnings 'utf8';   use common​::sense;

will leave utf8 warnings on. But below you say that common​::sense sets things to a defined set.

The code in question\, un-printfed\, is​:

  ${^WARNING_BITS} ^= ${^WARNING_BITS} ^ "...";

which is equivalent to

  ${^WARNING_BITS} =   ${^WARNING_BITS} ^ ${^WARNING_BITS} ^ "...";

Xoring the bitmask represented by "..." against ${^WARNING_BITS} *twice* just results in "..." again (unless it is shorter than ${^WARNING_BITS}\, in which case it is padded).

The new code would leave warning bits on.

Use common​::sense is supposed to set warnigns to a predefined set\,

That is precisely what ‘${^WARNING_BITS} = "..."’ does\, since ${^WARNING_BITS} contains all the warning settings (when lexical warnings are in effect).

not to disable some and enable others.

If you rephrase that as ‘disable some and enable *all* others’ or ‘enable some and disable all others’\, then it is exactly the same thing as setting it to a predefined set.

So it seems to me that the warning bits are no longer that\, warning bits\, but either non-warning bits or are being abused for something else\, which would be bad design.

I don't know what 5.15 actually does\, but if turning off warning bits causes errornous warnings\, then I would expect this to be treated as a bug in perl.

The exact value of ${^WARNING_BITS} has never been documented. It never will be documented. It’s a variable intended for warning.pm’s own use.

If you want to copy the value from one scope to another\, you can\, and you will get exactly the same warnings in that other scope. Anything more is unsupportable\, because it prevents bugs from being fixed.

Warnings are occurring now because ${^WARNING_BITS} is now undef when there are no warning bits (i.e.\, lexical warnings are not activated). This is the bug fix I was alluding to in the preceding paragraph. Copying the value of ${^WARNING_BITS} from one scope to another now *always* works\, not just when lexical warnings are enabled.

Now\, either I don't understand whats going on (then I would like to learn)\,

I hope I have clarified it enough. But I do find your first few sentences confusing. :-)

However\, if I am right and 5.15 abuses the warning bits for something else\, I would ask the p5p'ers to reconsider their design to something more sane.

Since I made the change\, you won’t be surprised I think it’s already sane. :-)

--

Father Chrysostomos

[p5pRT]

From schmorp@schmorp.de

On Mon\, Mar 05\, 2012 at 08​:44​:13PM -0800\, Father Chrysostomos via RT \perlbug\-followup@&#8203;perl\.org wrote​:

Maybe I am misunderstanding something. It sounds as though you are saying that

use warnings 'utf8';
use common​::sense;

will leave utf8 warnings on. But below you say that common​::sense sets things to a defined set.

Not at the moment\, but after the proposed patch\, it would\, because the patch only toggles some warning bits\, it doesn't set or reset any.

My understanding of that variable is that individual bits enable (when set) or disable (when clear) a warning (or fatality of it).

At the moment\, common​::sense always sets the variable to the same value​:

${^WARNING_BITS} = ${^WARNING_BITS} ^ ${^WARNING_BITS} ^ "...";

The patch just xor's some warning bits in the mask\, so it would enable some warnings\, disable others\, and keep others unchanged..

Xoring the bitmask represented by "..." against ${^WARNING_BITS} *twice* just results in "..." again (unless it is shorter than ${^WARNING_BITS}\, in which case it is padded).

Exactly\, the purpose is to not shorten the warning mask - after looking at the code\, I deemed it safer to keep warning_bits at the same length at all times (after all\, I rely on undocumented behaviour).

Older versions of common​::sense simply did this​:

  ${^WARNING_BITS} = "...";

which had the same effect\, but was less resistant to surprises.

Use common​::sense is supposed to set warnigns to a predefined set\,

That is precisely what ‘${^WARNING_BITS} = "..."’ does\, since ${^WARNING_BITS} contains all the warning settings (when lexical warnings are in effect).

So should $var = $var ^ $var ^ $value.

If this is not the case\, then $var doesn't contain the warning settings\, but something else.

not to disable some and enable others.

If you rephrase that as ‘disable some and enable *all* others’ or ‘enable some and disable all others’\, then it is exactly the same thing as setting it to a predefined set.

common​::sense is supposed to exactly set a predefined set of warnings\, as per the documentation (which starts with "no warnings"\, which hopefully disables all of them).

The xor-thing is only used to keep the warning bit mask at the length perl expects it\, while clearing all bits in it\, even if the precomputed mask is shorter.

I don't know what 5.15 actually does\, but if turning off warning bits causes errornous warnings\, then I would expect this to be treated as a bug in perl.

The exact value of ${^WARNING_BITS} has never been documented. It never will be documented. It’s a variable intended for warning.pm’s own use.

Right.

If you want to copy the value from one scope to another\, you can\, and you will get exactly the same warnings in that other scope. Anything more is unsupportable\, because it prevents bugs from being fixed.

But undef ^ undef ^ "str" gives "str"\, so that should work just as well.

Warnings are occurring now because ${^WARNING_BITS} is now undef when there are no warning bits (i.e.\, lexical warnings are not activated). This is the bug fix I was alluding to in the preceding paragraph. Copying the value of ${^WARNING_BITS} from one scope to another now *always* works\, not just when lexical warnings are enabled.

Now it's my turn to not understand it. common​::sense itself does not attempt to copy anything\, it wants to brutally override everything and set it to the warnings set it wishes to have\, everything else off.

I could understand if undef ^ undef ^ "str" would somehow give funny results\, but at leats here it doesn't matter whether the variable is undef or has some bitstring in it\, the expression gives the same value (modulo length).

I hope I have clarified it enough. But I do find your first few sentences confusing. :-)

Well\, thanks a lot for explaining it to me - since this is undocumented\, I can justw ait until there is a release and then look it up myself\, which I am of course fully prepared to.

But "$var ^ $var ^ $set" works regardless of whether var contains a bitmask or undef\, so it can't explain how some warnings are set that are not in $set.

So maybe there *is* something more fishy going on\, because all what you say\, and all what I think and understand\, seems to indicate that it should just work as it is.

Since I made the change\, you won’t be surprised I think it’s already sane. :-)

From what your description\, I would even agree it is sane\, but I can't see how your description explains anything\, because the end result should always be​:

  $var = "..."

And "..." usually has the right length (unless $var is undef\, in which case it gets extended).

--   The choice of a Deliantra\, the free code+content MORPG   -----==- _GNU_ http​://www.deliantra.net   ----==-- _ generation   ---==---(_)__ __ ____ __ Marc Lehmann   --==---/ / _ \/ // /\ \/ / schmorp@​schmorp.de   -=====/_/_//_/\_\,_/ /_/\_\

[p5pRT]

From zefram@fysh.org

Marc Lehmann wrote​:

Now it's my turn to not understand it. common​::sense itself does not attempt to copy anything\, it wants to brutally override everything and set it to the warnings set it wishes to have\, everything else off.

Your overriding isn't brutal enough. In the fiddling with ^=\, you're attempting to merge your desired warning flags into the existing ${^WARNING_BITS} value\, to maintain the existing length. It will be cleaner and more supported if you don't attempt to maintain any aspect of the existing value. You should just assign your target value directly to ${^WARNING_BITS}\, brutally overriding the existing value.

Quick demo​:

  our $w;   {   no warnings;   use warnings "void";   BEGIN { $w = ${^WARNING_BITS}; }   }   sub import { ${^WARNING_BITS} = $w; }

You have a more complex data flow where you perform the capture at build time and insert it into common/sense.pm as a literal. That doesn't affect the principle. The crucial part is "${^WARNING_BITS} = $w".

-zefram

[p5pRT]

From schmorp@schmorp.de

On Tue\, Mar 06\, 2012 at 11​:08​:56AM +0000\, Zefram \zefram@&#8203;fysh\.org wrote​:

Your overriding isn't brutal enough.

But how so?

In the fiddling with ^=\, you're attempting to merge your desired warning flags into the existing ${^WARNING_BITS} value\, to maintain the existing length.

Yup.

It will be cleaner and more supported if you don't attempt to maintain

How will it be more supported? It's not supported at all at the moment\, and doing it differently will not give me magic support for it.

It is also not cleaner because perl does not do bounds-checking\, so assigning a shorter value might cause undefined behaviour. If a common sense module survives into a newer version of perl\, this might well cause memory corruption or worse.

any aspect of the existing value. You should just assign your target value directly to ${^WARNING_BITS}\, brutally overriding the existing value.

That might well be the soltuion\, but I would like to understand first. Everything people said so far points at the current method being the best one\, and it should be working.

So if it isn't working\, then something else goes on that apparently nobody understands.

You have a more complex data flow where you perform the capture at build time and insert it into common/sense.pm as a literal. That doesn't affect the principle. The crucial part is "${^WARNING_BITS} = $w".

That's what the code does currently\, except by also preserving the length. That's what I was told by everybdy here too\, so something else that is badly understood is going on.

Before blindly patching common sense to potentially cause memory corruption I'd just like to understand it.

Note\, again\, I am happy for any help\, but I am fully aware that it's my duty alone to take care of it\, and I am certainly capable of fixing common​::sense when there is a perl release that breaks it's undocumented and unsupported access.

Now\, checking the documentation\, it's not actually fully undocumented (the variable is\, and perlvar points to "warnings" for more info\, but that link is dead\, so maybe it was supposed to be documented but isn't).

But sure\, if perl doesn't store a warning (bit) set anymore\, that's fair game. But if it does (or stores undef)\, the code as it should work\, so why doesn't it?

--   The choice of a Deliantra\, the free code+content MORPG   -----==- _GNU_ http​://www.deliantra.net   ----==-- _ generation   ---==---(_)__ __ ____ __ Marc Lehmann   --==---/ / _ \/ // /\ \/ / schmorp@​schmorp.de   -=====/_/_//_/\_\,_/ /_/\_\

[p5pRT]

From zefram@fysh.org

Marc Lehmann wrote​:

On Tue\, Mar 06\, 2012 at 11​:08​:56AM +0000\, Zefram \zefram@&#8203;fysh\.org wrote​:

Your overriding isn't brutal enough.

But how so?

Because it's not completely replacing the existing value.

How will it be more supported? It's not supported at all at the moment\,

Completely replacing the ${^WARNING_BITS} value with a value copied from ${^WARNING_BITS} in some other scope is supported\, or at least more supported than generating a novel value yourself. This is the copying that FC mentioned\, that had you mystified.

It is also not cleaner because perl does not do bounds-checking\,

There certainly is some lack of length checking in isWARN_on()\, which would matter if you were setting a very short value. But it's not an issue if you are copying a complete warning bitset that Perl gave you\, because that'll be long enough for all the warnings checked that way. Custom registered warning categories are checked via warnings​::enabled()\, which uses vec()\, which does check length.

Now\, checking the documentation\, it's not actually fully undocumented (the variable is\,

It's rather too undocumented for my liking. We ought to at least be explicit that the value isn't to be interpreted\, and the extent to which it's acceptable to copy values around. (Copying within one interpreter always OK; copying between processes only really OK when the source has no custom warning categories registered.)

 But if it does \(or stores undef\)\, the code as it should work\, so why

doesn't it?

I believe it gets the desired value of ${^WARNING_BITS} but the complaint is that in doing so it emits a warning\, which some downstream modules are testing for. The warning is to be expected if you perform bitwise operations on undef.

-zefram

[p5pRT]

From @cpansprout

On Tue Mar 06 02​:42​:00 2012\, schmorp@​schmorp.de wrote​:

Now it's my turn to not understand it. common​::sense itself does not attempt to copy anything\, it wants to brutally override everything and set it to the warnings set it wishes to have\, everything else off.

Well\, in a sense you are copying the value captured in sense.pm.PL and later assigning it in sense.pm.

From what your description\, I would even agree it is sane\, but I can't see how your description explains anything\, because the end result should always be​:

$var = "..."

And "..." usually has the right length (unless $var is undef\, in which case it gets extended).

At the time the the bit fiddling takes place\, there is no warnings pragma in scope yet\, so $^W is in effect. Instead of my patch you could precede the ${^WARNING_BITS} line with ‘local $^W;’. That would work\, too.

--

Father Chrysostomos

[p5pRT]

From @cpansprout

On Tue Mar 06 04​:41​:59 2012\, schmorp@​schmorp.de wrote​:

It is also not cleaner because perl does not do bounds-checking\, so assigning a shorter value might cause undefined behaviour. If a common sense module survives into a newer version of perl\, this might well cause memory corruption or worse.

I’ve just had a look at this code in mg.c​:

  STRLEN len;   const char *const p = SvPV_const(sv\, len);

  PL_compiling.cop_warnings   = Perl_new_warnings_bitfield(aTHX_ PL_compiling.cop_warnings\,   p\, len);

and this code in util.c​:

STRLEN * Perl_new_warnings_bitfield(pTHX_ STRLEN *buffer\, const char *const bits\,   STRLEN size) {   const MEM_SIZE len_wanted = sizeof(STRLEN) + size;   PERL_UNUSED_CONTEXT;   PERL_ARGS_ASSERT_NEW_WARNINGS_BITFIELD;

  buffer = (STRLEN*)   (specialWARN(buffer) ?   PerlMemShared_malloc(len_wanted) :   PerlMemShared_realloc(buffer\, len_wanted));   buffer[0] = size;   Copy(bits\, (buffer + 1)\, size\, char);   return buffer; }

Ouch!

I didn’t realise it was that bad.

It is storing the size of the buffer\, but then that stored size doesn’t seem to be used anywhere.

This small patch would fix that in the least intrusive way possible​:

Inline Patch

```diff diff --git a/util.c b/util.c index 1ff5913..87ca76d 100644 --- a/util.c +++ b/util.c @@ -2002,10 +2002,11 @@ S_ckwarn_common(pTHX_ U32 w) STRLEN * Perl_new_warnings_bitfield(pTHX_ STRLEN *buffer, const char *const bits, STRLEN size) { - const MEM_SIZE len_wanted = sizeof(STRLEN) + size; + const MEM_SIZE len_wanted = sizeof(STRLEN) + WARNsize; PERL_UNUSED_CONTEXT; PERL_ARGS_ASSERT_NEW_WARNINGS_BITFIELD; + size = WARNsize; buffer = (STRLEN*) (specialWARN(buffer) ? PerlMemShared_malloc(len_wanted) : ```

Does anyone see anything wrong with applying that now?

(Then\, after 5.16\, we could refactor it to avoid allocating the extra sizeof(STRLEN) bytes.)

--

Father Chrysostomos

[p5pRT]

From zefram@fysh.org

Father Chrysostomos via RT wrote​:

Does anyone see anything wrong with applying that now?

Yes\, it looks like you've completely misunderstood how the size is managed. Your change would copy a fixed number of bytes into the warning structure\, ignoring the actual size of the input.

As I noted earlier in this thread\, the core's internal warning bit checks don't check that there are enough bits in the warning vector. But that's fine as long as it's only checking the statically-allocated warning categories and the user never writes an abnormally short bitset into ${^WARNING_BITS}. This does provide yet another\, particularly easy\, way to make perl break memory discipline\, but it's through quite an explicit port into the internals. It won't arise if the user only writes bitsets previously read from the same place.

-zefram

[p5pRT]

From @cpansprout

On Tue Mar 06 13​:20​:44 2012\, zefram@​fysh.org wrote​:

Father Chrysostomos via RT wrote​:

Does anyone see anything wrong with applying that now?

Yes\, it looks like you've completely misunderstood

No\, I just wrote the patch too quickly. :-)

how the size is managed. Your change would copy a fixed number of bytes into the warning structure\, ignoring the actual size of the input.

As I noted earlier in this thread\, the core's internal warning bit checks don't check that there are enough bits in the warning vector. But that's fine as long as it's only checking the statically-allocated warning categories and the user never writes an abnormally short bitset into ${^WARNING_BITS}. This does provide yet another\, particularly easy\, way to make perl break memory discipline\, but it's through quite an explicit port into the internals. It won't arise if the user only writes bitsets previously read from the same place.

What Marc Lehmann says about an old common​::sense being used with a newer perl is a valid concern.

Here is a better version​:

Inline Patch

```diff diff --git a/util.c b/util.c index 1ff5913..a147ae0 100644 --- a/util.c +++ b/util.c @@ -2002,7 +2002,7 @@ S_ckwarn_common(pTHX_ U32 w) STRLEN * Perl_new_warnings_bitfield(pTHX_ STRLEN *buffer, const char *const bits, STRLEN size) { - const MEM_SIZE len_wanted = sizeof(STRLEN) + size; + const MEM_SIZE len_wanted = sizeof(STRLEN) + WARNsize; PERL_UNUSED_CONTEXT; PERL_ARGS_ASSERT_NEW_WARNINGS_BITFIELD; @@ -2012,6 +2012,8 @@ Perl_new_warnings_bitfield(pTHX_ STRLEN *buffer, ```

const char const bits,   PerlMemShared_realloc(buffer\, len_wanted));   buffer[0] = size;   Copy(bits\, (buffer + 1)\, size\, char); + if (size \< WARNsize) + Zero(bits\, (char \)(buffer + 1) + size\, WARNsize - size\, char);   return buffer; }

--

Father Chrysostomos

[p5pRT]

From @cpansprout

On Tue Mar 06 13​:28​:58 2012\, sprout wrote​:

On Tue Mar 06 13​:20​:44 2012\, zefram@​fysh.org wrote​:

Father Chrysostomos via RT wrote​:

Does anyone see anything wrong with applying that now?

Yes\, it looks like you've completely misunderstood

No\, I just wrote the patch too quickly. :-)

how the size is managed. Your change would copy a fixed number of bytes into the warning structure\, ignoring the actual size of the input.

As I noted earlier in this thread\, the core's internal warning bit checks don't check that there are enough bits in the warning vector. But that's fine as long as it's only checking the statically-allocated warning categories and the user never writes an abnormally short bitset into ${^WARNING_BITS}. This does provide yet another\, particularly easy\, way to make perl break memory discipline\, but it's through quite an explicit port into the internals. It won't arise if the user only writes bitsets previously read from the same place.

What Marc Lehmann says about an old common​::sense being used with a newer perl is a valid concern.

Here is a better version​:

diff --git a/util.c b/util.c index 1ff5913..a147ae0 100644 --- a/util.c +++ b/util.c @​@​ -2002\,7 +2002\,7 @​@​ S_ckwarn_common(pTHX_ U32 w) STRLEN * Perl_new_warnings_bitfield(pTHX_ STRLEN *buffer\, const char *const bits\, STRLEN size) { - const MEM_SIZE len_wanted = sizeof(STRLEN) + size; + const MEM_SIZE len_wanted = sizeof(STRLEN) + WARNsize; PERL_UNUSED_CONTEXT; PERL_ARGS_ASSERT_NEW_WARNINGS_BITFIELD;

@​@​ -2012\,6 +2012\,8 @​@​ Perl_new_warnings_bitfield(pTHX_ STRLEN *buffer\, const char *const bits\, PerlMemShared_realloc(buffer\, len_wanted)); buffer[0] = size; Copy(bits\, (buffer + 1)\, size\, char); + if (size \< WARNsize) + Zero(bits\, (char *)(buffer + 1) + size\, WARNsize - size\, char); return buffer; }

Maybe I should actually try compiling things before submitting patches. :-)

Inline Patch

```diff diff --git a/util.c b/util.c index 1ff5913..256abc5 100644 --- a/util.c +++ b/util.c @@ -2002,7 +2002,7 @@ S_ckwarn_common(pTHX_ U32 w) STRLEN * Perl_new_warnings_bitfield(pTHX_ STRLEN *buffer, const char *const bits, STRLEN size) { - const MEM_SIZE len_wanted = sizeof(STRLEN) + size; + const MEM_SIZE len_wanted = sizeof(STRLEN) + WARNsize; PERL_UNUSED_CONTEXT; PERL_ARGS_ASSERT_NEW_WARNINGS_BITFIELD; @@ -2012,6 +2012,8 @@ Perl_new_warnings_bitfield(pTHX_ STRLEN *buffer, ```

const char const bits,   PerlMemShared_realloc(buffer\, len_wanted));   buffer[0] = size;   Copy(bits\, (buffer + 1)\, size\, char); + if (size \< WARNsize) + Zero((char \)(buffer + 1) + size\, WARNsize - size\, char);   return buffer; }

--

Father Chrysostomos

[p5pRT]

From zefram@fysh.org

Father Chrysostomos via RT wrote​:

- const MEM_SIZE len_wanted = sizeof(STRLEN) + size; + const MEM_SIZE len_wanted = sizeof(STRLEN) + WARNsize;

No\, still drastically wrong. size can legitimately be greater than the fixed WARNsize\, due to dynamic category registration. You mustn't write those extra octets past the end of the allocated space (as this version of your patch does)\, nor is it acceptable to just drop them.

The kind of munging you can sensibly do is to zero-pad an input that was shorter than WARNsize. Any input of WARNsize or longer is already handled correctly.

-zefram

[p5pRT]

From schmorp@schmorp.de

On Tue\, Mar 06\, 2012 at 08​:47​:17AM -0800\, Father Chrysostomos via RT \perlbug\-followup@&#8203;perl\.org wrote​:

At the time the the bit fiddling takes place\, there is no warnings pragma in scope yet\, so $^W is in effect. Instead of my patch you could

Ah\, that makes a lot more sense\, well do that\, thanks a lot.

Howeever\, $^W is an obsolete feature that breaks a lot of code\, so anything that still uses it is in need of fixing. I know make test usually runs tests with -w\, but if enabling warnings for foreign code breaks anything\, then whoever forced warnings on gets to keep the pieces normally.

If your patch is part of some work fixing this $^W mess\, then all the power to you\, thank you very much :)

--   The choice of a Deliantra\, the free code+content MORPG   -----==- _GNU_ http​://www.deliantra.net   ----==-- _ generation   ---==---(_)__ __ ____ __ Marc Lehmann   --==---/ / _ \/ // /\ \/ / schmorp@​schmorp.de   -=====/_/_//_/\_\,_/ /_/\_\

[p5pRT]

From schmorp@schmorp.de

On Tue\, Mar 06\, 2012 at 01​:05​:34PM +0000\, Zefram \zefram@&#8203;fysh\.org wrote​:

Your overriding isn't brutal enough.

But how so?

Because it's not completely replacing the existing value.

That is what it does\, yes\, but I asked how it isn't brutal enough\, which you didn't answer - the code zeroes all warning bits and sets the ones it wants. What else is needed?

Completely replacing the ${^WARNING_BITS} value with a value copied from ${^WARNING_BITS} in some other scope is supported\, or at least more

Is there a reference in the documentation that you could refer me to\, or is this lore?

supported than generating a novel value yourself. This is the copying that FC mentioned\, that had you mystified.

That's not enough for common​::sense\, unfortunately. If that means I have to reverse engineer perl 5.16\, then that's how it is to be.

would matter if you were setting a very short value. But it's not an issue if you are copying a complete warning bitset that Perl gave you\,

That is what the code currently does (assuming a bitset is a bitset) - it sets all bits it wants to set and clears all bits it wants cleared.

because that'll be long enough for all the warnings checked that way.

Not under the conditions I wrote about\, but that has been clarified elsewhere.

It's rather too undocumented for my liking. We ought to at least be explicit that the value isn't to be interpreted\, and the extent to which it's acceptable to copy values around. (Copying within one interpreter always OK; copying between processes only really OK when the source has no custom warning categories registered.)

If it's a bitset\, then current common​::sense ought to work\, if not\, then it's not enough\, because common​::sense interprets it as a bitset\, and at the very least\, needs to interpret it as a string\, because there is no way to dump a perl scalar in a way that fully restores it\, without knowing it's content.

I believe it gets the desired value of ${^WARNING_BITS} but the complaint is that in doing so it emits a warning\, which some downstream modules are testing for. The warning is to be expected if you perform bitwise operations on undef.

Ah\, so the problem is indeed using the obsolete $^W - this is a bug in the code that enables it.

At least in the past\, $^W has had the semantics of enabling warnings for all code\, not just code that requests warnings.

"use warnings" fixes that\, because it allows code to enable warnings it supports.

Enabling $^W can be done\, but if that generates warnings\, that's the problem of whoever used $^W (or e.g. -w) - if you patch modules to use warnings they were not written for (which is what $^W does) then you get to keep the pieces.

So it seems current common​::sense works\, and nothing needs to be changed in it\, or 5.16 - the problem is in whatever code that enables warnings for code that didn't request it (common​::sense didn't).

--   The choice of a Deliantra\, the free code+content MORPG   -----==- _GNU_ http​://www.deliantra.net   ----==-- _ generation   ---==---(_)__ __ ____ __ Marc Lehmann   --==---/ / _ \/ // /\ \/ / schmorp@​schmorp.de   -=====/_/_//_/\_\,_/ /_/\_\

[p5pRT]

From @cpansprout

On Tue Mar 06 16​:07​:09 2012\, zefram@​fysh.org wrote​:

Father Chrysostomos via RT wrote​:

- const MEM_SIZE len_wanted = sizeof(STRLEN) + size; + const MEM_SIZE len_wanted = sizeof(STRLEN) + WARNsize;

No\, still drastically wrong. size can legitimately be greater than the fixed WARNsize\, due to dynamic category registration. You mustn't write those extra octets past the end of the allocated space (as this version of your patch does)\, nor is it acceptable to just drop them.

The kind of munging you can sensibly do is to zero-pad an input that was shorter than WARNsize. Any input of WARNsize or longer is already handled correctly.

Thank you for your patience and your explanations. How about this patch?

Inline Patch

```diff diff --git a/util.c b/util.c index 1ff5913..e6b5fa5 100644 --- a/util.c +++ b/util.c @@ -2002,7 +2002,8 @@ S_ckwarn_common(pTHX_ U32 w) STRLEN * Perl_new_warnings_bitfield(pTHX_ STRLEN *buffer, const char *const bits, STRLEN size) { - const MEM_SIZE len_wanted = sizeof(STRLEN) + size; + const MEM_SIZE len_wanted = + sizeof(STRLEN) + (size > WARNsize ? size : WARNsize); PERL_UNUSED_CONTEXT; PERL_ARGS_ASSERT_NEW_WARNINGS_BITFIELD; @@ -2012,6 +2013,8 @@ Perl_new_warnings_bitfield(pTHX_ STRLEN *buffer, ```

const char const bits,   PerlMemShared_realloc(buffer\, len_wanted));   buffer[0] = size;   Copy(bits\, (buffer + 1)\, size\, char); + if (size \< WARNsize) + Zero((char \)(buffer + 1) + size\, WARNsize - size\, char);   return buffer; }

Without it\, the problem that Marc mentioned will occur if a common​::sense is installed for 5.12 but then inadvertently used for 5.16.

--

Father Chrysostomos

[p5pRT]

From zefram@fysh.org

Father Chrysostomos via RT wrote​:

Thank you for your patience and your explanations. How about this patch?

Much better. I'd be inclined to make one further change​: set buffer[0] to the padded size rather than the original size. I can argue that one both ways\, though.

Without it\, the problem that Marc mentioned will occur if a common​::sense is installed for 5.12 but then inadvertently used for 5.16.

I don't think that's a situation that we should care about to the slightest degree.

-zefram

[p5pRT]

From @Leont

On Wed\, Mar 7\, 2012 at 10​:24 PM\, Father Chrysostomos via RT \perlbug\-followup@&#8203;perl\.org wrote​:

Without it\, the problem that Marc mentioned will occur if a common​::sense is installed for 5.12 but then inadvertently used for 5.16.

I think that on the long run\, that use-case is not tenable. common​::sense should install to arch instead of lib so that next time we change ${^WARNING_BITS} it doesn't get broken this way again. Or am I missing something?

Leon

[p5pRT]

From @cpansprout

On Wed Mar 07 13​:39​:12 2012\, zefram@​fysh.org wrote​:

Father Chrysostomos via RT wrote​:

Thank you for your patience and your explanations. How about this patch?

Much better. I'd be inclined to make one further change​: set buffer[0] to the padded size rather than the original size. I can argue that one both ways\, though.

I though about that\, too. I decided to leave the stored length the same\, so that what is retrieved from ${^WARNING_BITS} will continue to be the same as what was assigned. It won’t make much difference in practice\, though.

I’ve made the change with commit 5af88345d9b.

--

Father Chrysostomos

[p5pRT]

From @cpansprout

On Wed Mar 07 12​:35​:42 2012\, schmorp@​schmorp.de wrote​:

On Tue\, Mar 06\, 2012 at 01​:05​:34PM +0000\, Zefram \zefram@&#8203;fysh\.org wrote​:

Completely replacing the ${^WARNING_BITS} value with a value copied from ${^WARNING_BITS} in some other scope is supported\, or at least more

Is there a reference in the documentation that you could refer me to\, or is this lore?

The latter. It’s a somewhat-known fact among Perl geeks that $^H %^H and ${^WARNING_BITS} describe the lexical pragmata. Therefore it should be possible to copy them from one scope to another\, right?

The fact that ${^WARNING_BITS} follows the same scoping as the other variables was not documented\, so I added that to perlvar in commit 44567c86.

supported than generating a novel value yourself. This is the copying that FC mentioned\, that had you mystified.

That's not enough for common​::sense\, unfortunately.

Since I fixed the bad reads a few minutes minutes ago\, it should be enough for 5.16.

It's rather too undocumented for my liking. We ought to at least be explicit that the value isn't to be interpreted\, and the extent to which it's acceptable to copy values around. (Copying within one interpreter always OK; copying between processes only really OK when the source has no custom warning categories registered.)

I documented it a little better\, but not with that much detail. I couldn’t think of a way to word it that would not subtract from the sum of human knowledge.

Ah\, so the problem is indeed using the obsolete $^W - this is a bug in the code that enables it.

At least in the past\, $^W has had the semantics of enabling warnings for all code\, not just code that requests warnings.

"use warnings" fixes that\, because it allows code to enable warnings it supports.

Enabling $^W can be done\, but if that generates warnings\, that's the problem of whoever used $^W (or e.g. -w) - if you patch modules to use warnings they were not written for (which is what $^W does) then you get to keep the pieces.

While I agree with that in theory\, I find it unpractical. While I would like to change EU​:MM’s default (which common​::sense’s own test suit is subjected to\, since it makes no effort to work around it)\, it’s not a battle I’m prepared to fight just yet.

It seems to me that common​::sense would be easier to use if users thereof didn’t have to put BEGIN { $^W = 0 } in their test suites. But you are free to disagree of course. (Yes\, that is just a workaround for someone else’s problem\, but I do that all the time.)

(On the other hand\, I *do* find $^W useful sometimes. I used to use it to control warnings from Test​::More​::cmp_ok\, but then later versions made the warnings mandatory\, via ‘use warnings’\, so for the module in question I bundled an old version of Test​::More. :-)

--

Father Chrysostomos

[p5pRT]

From @cpansprout

On Wed Mar 07 14​:11​:24 2012\, LeonT wrote​:

On Wed\, Mar 7\, 2012 at 10​:24 PM\, Father Chrysostomos via RT \perlbug\-followup@&#8203;perl\.org wrote​:

Without it\, the problem that Marc mentioned will occur if a common​::sense is installed for 5.12 but then inadvertently used for 5.16.

I think that on the long run\, that use-case is not tenable. common​::sense should install to arch instead of lib so that next time we change ${^WARNING_BITS} it doesn't get broken this way again. Or am I missing something?

Yes\, it should install to arch.

But setting a variable from pure-Perl still shouldn’t cause bad reads. :-)

With regard to installation directories\, I have found myself in situations where I had to get something working *immediately* and copying several .pm files manually was the only choice. So mistakes can be made easily.

--

Father Chrysostomos

[p5pRT]

From schmorp@schmorp.de

On Wed\, Mar 07\, 2012 at 04​:50​:40PM -0800\, Father Chrysostomos via RT \perlbug\-followup@&#8203;perl\.org wrote​:

Is there a reference in the documentation that you could refer me to\, or is this lore?

The latter. It’s a somewhat-known fact among Perl geeks that $^H %^H and ${^WARNING_BITS} describe the lexical pragmata. Therefore it should be possible to copy them from one scope to another\, right?

Well\, sounds like a non-sequitur to me - when I read a manual whcih says "this variable contains this (and has these scoping behaviour)" then to me\, assuming that I can freely copy it would be a large leap.

Perl is pretty magical\, but the same is true for C - if you have a pointer variable pointing at some hiddne structure\, would you assue you could just copy it? For example\, after the program has restarted? :)

Now\, perl documentation is often not very specific\, and in practise\, this is not a problem - there is always a trade-off between how much stuff breaks\, and there is the traditional (mostly undocumented) perl runtime model that you better don't break.

Wouldn't waste too much thinking on these issues.

My problem here was solely that nobody could explain the behaviour to me\, the proposed patch looked too magical\, and I generally need to understand my own software\, otherwise I can't maintain it :)

So\, thanks a lot for staying with me in this.

[$^W]

While I agree with that in theory\, I find it unpractical. While I would like to change EU​:MM’s default (which common​::sense’s own test suit is subjected to\, since it makes no effort to work around it)\, it’s not a battle I’m prepared to fight just yet.

Well\, the obvious fix would be to change -w to work like --acFilMnpsSx\, i.e. they act on the main program - the rest can use warnings.

Disabling -w for modules cannot break a well-written module after all.

Especially -c compares well to -w\, because both do checks on the program. For purely practical reasons\, -w should behave like -c and use modules alone.

Anything else breaks perl for module authors who don't agree with all warnings\, because they always have to disable warnings\, even though they should be disabled by default.

It seems to me that common​::sense would be easier to use if users thereof didn’t have to put BEGIN { $^W = 0 } in their test suites. But

Well\, I am one of those\, and it's not common​::sense related at all.

Keep in mind that the problem is the broken -w behaviour\, or the broken behaviour of scripts that assume it does something useful with my code. This isn't helped by the -w documentation\, which doesn't warn about ill effects on other people's code (by forcing new semantics on it).

What probably wasn't obvious to you is the fact hat common​::sense\, among other things\, is supposed to get rid of this line in every one of my modules... the suffering\, it is real.

you are free to disagree of course. (Yes\, that is just a workaround for someone else’s problem\, but I do that all the time.)

I already said I will change that\, you need tot rust my words\, really :)

(On the other hand\, I *do* find $^W useful sometimes. I used to use it to control warnings from Test​::More​::cmp_ok\, but then later versions made the warnings mandatory\, via ‘use warnings’\, so for the module in question I bundled an old version of Test​::More. :-)

Obviously\, -w over time loses is usefulness\, while keeping its damaging effects.

--   The choice of a Deliantra\, the free code+content MORPG   -----==- _GNU_ http​://www.deliantra.net   ----==-- _ generation   ---==---(_)__ __ ____ __ Marc Lehmann   --==---/ / _ \/ // /\ \/ / schmorp@​schmorp.de   -=====/_/_//_/\_\,_/ /_/\_\

[p5pRT]

From schmorp@schmorp.de

On Wed\, Mar 07\, 2012 at 11​:10​:34PM +0100\, Leon Timmermans \fawaka@&#8203;gmail\.com wrote​:

I think that on the long run\, that use-case is not tenable.

Absolutely - but silent memory corruption is usually worse than wrong warnings.

common​::sense should install to arch instead of lib so that next time we change ${^WARNING_BITS} it doesn't get broken this way again. Or am I missing something?

Neither arch nor lib are obviously correct\, because the dependence is on the warning bitset\, not perl-arch.

Now\, the warning bit set has been very stable - did it ever change\, as opposed to getting extended? How likely is it that it changes? Wouldn't that mean a warning category gets removed?

I the real world\, there are trade-offs\, and in this case\, it seems the trade-off says that if it works from 5.8 to 5.16\, then it can't be that much of a problem.

Certainly not compared to the assumptions common​::sense makes about the variable being a bitset in the first place\, being able to serialise it\, and it being stable between program runs.

--   The choice of a Deliantra\, the free code+content MORPG   -----==- _GNU_ http​://www.deliantra.net   ----==-- _ generation   ---==---(_)__ __ ____ __ Marc Lehmann   --==---/ / _ \/ // /\ \/ / schmorp@​schmorp.de   -=====/_/_//_/\_\,_/ /_/\_\

[p5pRT]

From @ikegami

On Thu\, Mar 8\, 2012 at 3​:35 AM\, Marc Lehmann \schmorp@&#8203;schmorp\.de wrote​:

Neither arch nor lib are obviously correct\, because the dependence is on the warning bitset\, not perl-arch.

Because people configure Perl to reach into the libraries of other builds of Perl\, arch is not just used for architecture-specific stuff\, but for Perl-version-specific and build-specific stuff. It is correct\, even if not obvious.

- Eric

[p5pRT]

From @ribasushi

Zefram wrote​:

Father Chrysostomos via RT wrote​:

Without it\, the problem that Marc mentioned will occur if a common​::sense is installed for 5.12 but then inadvertently used for 5.16.

I don't think that's a situation that we should care about to the slightest degree.

This is somewhat wrong. Think of bundled/fatpacked dists. Especially in this case when backwards compatibility is virtually free\, tossing stuff like "should not care about to the slightest degree" is kinda misguided.

Cheers

[p5pRT]

From @ikegami

On Sun\, Mar 11\, 2012 at 5​:20 AM\, Peter Rabbitson \rabbit\-p5p@&#8203;rabbit\.uswrote​:

Zefram wrote​:

Father Chrysostomos via RT wrote​:

Without it\, the problem that Marc mentioned will occur if a common​::sense is installed for 5.12 but then inadvertently used for 5.16.

I don't think that's a situation that we should care about to the slightest degree.

This is somewhat wrong. Think of bundled/fatpacked dists. Especially in this case when backwards compatibility is virtually free\, tossing stuff like "should not care about to the slightest degree" is kinda misguided.

I disagree. Perl has never been binary compatible between major versions. If you copy internal state from version\, you can't use it in a different version. This is nothing new\, and it's a problem with common-sense that's easily fixable.

- Eric

[p5pRT]

From @cpansprout

This was resolved by the new common​::sense​:

cpan> m common​::sense Module id = common​::sense   CPAN_USERID MLEHMANN (Marc Lehmann \schmorp@&#8203;schmorp\.de)   CPAN_VERSION 3.5   CPAN_FILE M/ML/MLEHMANN/common-sense-3.5.tar.gz   UPLOAD_DATE 2012-03-24   INST_FILE (not installed)

--

Father Chrysostomos

[p5pRT]

From [Unknown Contact. See original ticket]

This was resolved by the new common​::sense​:

cpan> m common​::sense Module id = common​::sense   CPAN_USERID MLEHMANN (Marc Lehmann \schmorp@&#8203;schmorp\.de)   CPAN_VERSION 3.5   CPAN_FILE M/ML/MLEHMANN/common-sense-3.5.tar.gz   UPLOAD_DATE 2012-03-24   INST_FILE (not installed)

--

Father Chrysostomos

[p5pRT]

@cpansprout - Status changed from 'open' to 'resolved'