Reini Urban wrote:
On 12/18/2015 02:48 AM, L Walsh wrote:
I am seeing, what I think is bug:

http://www.nntp.perl.org/group/perl.perl5.porters/2015/06/msg228888.html

No, you don't use the width specifier.

But I am only seeing it from 1 5.22.0 client:
(http://www.cpantesters.org/cpan/report/7cbf1ee4-6c18-1014-b5bf-e4f7913d07a7)

Wasn't in 5.22.0 and not fixed until 5.22.1?

The problem is your code with HASH and ARRAY, which you can easily see
if you would tidy up your code to be readable.
For those cases you return no % format specifier, only "...".
So you get these warnings.

Why would I see it w/only 1 tester?

Maybe because your PREREQ's are fucked up, so nobody is able to test P.
Types/Core and Xporter are not installable. Call us lucky
----
   ???  :
"P" by the versions:
1.1.23 -- 254 PASS 0 FAIL
1.1.24 -- 344 PASS 2 FAILS on Windows
1.1.26 -- everything was broken due to some circular dependency
1.1.27 -- 388 PASS, 1 FAIL (Windows)
1.1.28 -- 287 PASS, 3 fails: 2 on windows w/5.20.0 & 5.20.1 and on 5.8.1
Types::Core:
0.1.8  -- 774 PASS 0 FAIL  (out since July 5th, 2015)
Xporter:
0.1.2  -- 1004 PASS 2 UNKNOWN (out since july, 2014)

----

So how is it that you proclaim Types::Core and Xporter
not to be installable, when there are no recorded fails
but over 700 and 1000 successful installs & tests?

Hmmm... maybe you haven't actually installed Types::Core
or Xporter in the past several months?  I see that the
pre-reqs requiring older versions -- I'll be sure to fix
that.

I'm a bit naive when it comes to testing methodology,  as
I'd think that people would do a get/install
of Types::Core & Xporter before P -- which, by default, would
fetch the latest versions.  I wouldn't normally invest much
time or effort for people who deliberately use old versions
in an attempt to generate failure cases.

Maybe you weren't aware, but P was my first CPAN module, almost
20 versions of which were just to get it to work with
the testing platform -- which which I was completely
unfamiliar.

As for the warning on sprintf, while it makes sense to
have an error for too few arguments to support a format
statement, it makes no logical sense to call an extra
argument "redundant". Not needed != redundant. It's not a 2nd format statement.

Why should sprintf warn about unneeded or unused arguments?

It doesn't follow the C standard sprintf in this regard, where
it states that the format specifier:

 The  format  string  is a character string, beginning and ending in its
 initial shift state, if any.  The format string is composed of zero  or
 more   directives:  ordinary  characters  (not  %),  which  are  copied
 unchanged to the output stream; and conversion specifications, each  of
 which results in fetching zero or more subsequent arguments.

Since you point out that the fmt string contains nothing but ordinary
characters, they should be copied unchanged to the output stream.  It
also says that conversion specifiers can result in *fetching* 0 or more
arguments from the argument list, but I've never seen documentation
for sprintf saying all arguments must be consumed.

It would appear that randomly changing sprintf's behavior is another
reason to use 'P' -- which would normally isolate the user from
such random changes.  From what you say, appending "%.0s", to the
format spec, should workaround this new 'behavior'?

thanks,
-l








Reply via email to