print/printf/say/sort (...) interpreted as function limited to " " as a whitespace in front of "("

[p5pRT]

Migrated from rt.perl.org#122150 (status was 'open')

Searchable as RT122150$

[p5pRT]

From @avar

Created by @avar

This is a minor bug that's been present ever since the perl 4 era. We have a warning that's supposed to warn about confusing use of print/printf/say/sort as a function\, i.e. this is OK​:

  $ ./perl -we 'print("")'

But this is warned about​:

  $ ./perl -we 'print ("")'   print (...) interpreted as function at -e line 1.

However S_checkcomma() in toke.c that implements this just does​:

  if (*s == ' ' && s[1] == '(') { /* XXX gotta be a better way */

So we will only catch cases of /\b(?​:print|printf|say|sort) \(/\, but we should instead do the equivalent of matching any non-zero whitespace\, including newlines and tabs\, i.e. something like /\b(?​:print|printf|say|sort)\s+\(/s.

The function already uses the correct isSPACE() macro later on\, the code just needs to be re-arranged to use that to eat up space between the function and "("\, and warn if there's any.

Perl Info

``` Flags: category=core severity=low Site configuration information for perl 5.21.2: Configured by avar at Sat Jun 21 13:02:19 UTC 2014. Summary of my perl5 (revision 5 version 21 subversion 2) configuration: Local Commit: 946bd120154b4b2b68a03ca473e15e5f03eb2ff6 Ancestor: 04e0f0c28a521a290f29301e7b2abe43d65a5339 Platform: osname=linux, osvers=3.2.0-4-amd64, archname=x86_64-linux-thread-multi uname='linux u.nix.is 3.2.0-4-amd64 #1 smp debian 3.2.35-2 x86_64 gnulinux ' config_args='-DDEBUGGING=both -Doptimize=-ggdb3 -Dusethreads -Dprefix=/home/avar/perl5/installed -Dusedevel -des' hint=recommended, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-ggdb3', cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include' ccversion='', gccversion='4.2.1 Compatible Debian Clang 3.3 (branches/release_33)', 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='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='cc', ldflags =' -fstack-protector -L/usr/local/lib' libpth=/usr/local/lib /usr/include/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib libs=-lnsl -ldb -ldl -lm -lcrypt -lutil -lpthread -lc perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc libc=libc-2.18.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.18' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E' cccdlflags='-fPIC', lddlflags='-shared -ggdb3 -L/usr/local/lib -fstack-protector' Locally applied patches: d1e978ede81bb0602bdb1f26093a7b58d245bcec 946bd120154b4b2b68a03ca473e15e5f03eb2ff6 @INC for perl 5.21.2: lib /home/avar/perl5/installed/lib/site_perl/5.21.2/x86_64-linux-thread-multi /home/avar/perl5/installed/lib/site_perl/5.21.2 /home/avar/perl5/installed/lib/5.21.2/x86_64-linux-thread-multi /home/avar/perl5/installed/lib/5.21.2 /home/avar/perl5/installed/lib/site_perl . Environment for perl 5.21.2: HOME=/home/avar LANG=en_US.UTF-8 LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/home/avar/local/bin:/home/avar/perl5/installed/bin:/home/v-perlbrew/perl5/perlbrew/perls/perl-5.19.6/bin:/home/v-perlbrew/perl5/perlbrew/bin:/home/v-perlbrew/perl5/perlbrew/perls/current/bin:/home/avar/local/bin:/home/avar/g/misc-scripts:/home/avar/bin:/usr/local/bin:/usr/bin:/bin:/usr/games PERLDOC=-MPod::Text::Ansi PERL_BADLANG (unset) SHELL=/bin/bash ```

[p5pRT]

From @jkeenan

On Sat Jun 21 06​:29​:01 2014\, avar wrote​:

This is a bug report for perl from avar@​cpan.org\, generated with the help of perlbug 1.40 running under perl 5.21.2.

----------------------------------------------------------------- [Please describe your issue here]

This is a minor bug that's been present ever since the perl 4 era. We have a warning that's supposed to warn about confusing use of print/printf/say/sort as a function\, i.e. this is OK​:

$ ./perl -we 'print("")'

But this is warned about​:

$ ./perl -we 'print ("")' print (...) interpreted as function at -e line 1.

However S_checkcomma() in toke.c that implements this just does​:

if (*s == ' ' && s[1] == '(') { /* XXX gotta be a better way */

So we will only catch cases of /\b(?​:print|printf|say|sort) \(/\, but we should instead do the equivalent of matching any non-zero whitespace\, including newlines and tabs\, i.e. something like /\b(?​:print|printf|say|sort)\s+\(/s.

The function already uses the correct isSPACE() macro later on\, the code just needs to be re-arranged to use that to eat up space between the function and "("\, and warn if there's any.

If we've lived with this bug for 20 years\, I imagine some would say\, "Why can't we live with it for another 20 years?"

More to the point\, what might break if we fixed it?

Could you provide tests that would demonstrate that the bug is fixed if we do decide to fix it?

Thank you very much. Jim Keenan

[p5pRT]

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

[p5pRT]

From @avar

On Sun\, Jun 29\, 2014 at 3​:11 AM\, James E Keenan via RT \perlbug\-followup@​perl\.org wrote​:

On Sat Jun 21 06​:29​:01 2014\, avar wrote​:

This is a bug report for perl from avar@​cpan.org\, generated with the help of perlbug 1.40 running under perl 5.21.2.

----------------------------------------------------------------- [Please describe your issue here]

This is a minor bug that's been present ever since the perl 4 era. We have a warning that's supposed to warn about confusing use of print/printf/say/sort as a function\, i.e. this is OK​:

$ ./perl -we 'print("")'

But this is warned about​:

$ ./perl -we 'print ("")' print (...) interpreted as function at -e line 1.

However S_checkcomma() in toke.c that implements this just does​:

if (*s == ' ' && s[1] == '(') { /* XXX gotta be a better way */

So we will only catch cases of /\b(?​:print|printf|say|sort) \(/\, but we should instead do the equivalent of matching any non-zero whitespace\, including newlines and tabs\, i.e. something like /\b(?​:print|printf|say|sort)\s+\(/s.

The function already uses the correct isSPACE() macro later on\, the code just needs to be re-arranged to use that to eat up space between the function and "("\, and warn if there's any.

If we've lived with this bug for 20 years\, I imagine some would say\, "Why can't we live with it for another 20 years?"

It's certainly not very high priority\, just something I noticed while spelunking through the source and thought I'd report.

More to the point\, what might break if we fixed it?

The behavior of the parser would still be the same\, it would just warn in more cases than it does now. So nothing would break\, but the warning would be corrected.

Could you provide tests that would demonstrate that the bug is fixed if we do decide to fix it?

Since the warning literally checks for " " followed by "(" but should check for any non-zero amount of whitespace the test is just to test that things like​: "print ('')" "print\n('')" etc. warn\, with some combinations of whitespace\, i.e. [\n\t ] etc.

But as long is it's using the isSPACE() macro instead of the current test it'll work as well as anything else that's eating up whitespace in the parser.

[p5pRT]

From @tux

On Sun\, 29 Jun 2014 12​:58​:07 +0200\, Ævar Arnfjörð Bjarmason \avar@​cpan\.org wrote​:

This is a minor bug that's been present ever since the perl 4 era. We have a warning that's supposed to warn about confusing use of print/printf/say/sort as a function\, i.e. this is OK​:

$ ./perl -we 'print("")'

But this is warned about​:

$ ./perl -we 'print ("")' print (...) interpreted as function at -e line 1.

I agree with Abigail that this could be nominated to one of the worst warnings ever added to perl.

In *my* perception the warning is the wrong way round.

Just remove the warning completely.

However S_checkcomma() in toke.c that implements this just does​:

if (*s == ' ' && s[1] == '(') { /* XXX gotta be a better way */

So we will only catch cases of /\b(?​:print|printf|say|sort) \(/\, but we should instead do the equivalent of matching any non-zero whitespace\, including newlines and tabs\, i.e. something like /\b(?​:print|printf|say|sort)\s+\(/s.

The function already uses the correct isSPACE() macro later on\, the code just needs to be re-arranged to use that to eat up space between the function and "("\, and warn if there's any.

If we've lived with this bug for 20 years\, I imagine some would say\, "Why can't we live with it for another 20 years?"

It's certainly not very high priority\, just something I noticed while spelunking through the source and thought I'd report.

More to the point\, what might break if we fixed it?

The behavior of the parser would still be the same\, it would just warn in more cases than it does now. So nothing would break\, but the warning would be corrected.

Could you provide tests that would demonstrate that the bug is fixed if we do decide to fix it?

Fix it by removing the warning.

Since the warning literally checks for " " followed by "(" but should check for any non-zero amount of whitespace the test is just to test that things like​: "print ('')" "print\n('')" etc. warn\, with some combinations of whitespace\, i.e. [\n\t ] etc.

But as long is it's using the isSPACE() macro instead of the current test it'll work as well as anything else that's eating up whitespace in the parser.

-- H.Merijn Brand http​://tux.nl Perl Monger http​://amsterdam.pm.org/ using perl5.00307 .. 5.19 porting perl5 on HP-UX\, AIX\, and openSUSE http​://mirrors.develooper.com/hpux/ http​://www.test-smoke.org/ http​://qa.perl.org http​://www.goldmark.org/jeff/stupid-disclaimers/

[p5pRT]

From @ikegami

On Sun\, Jun 29\, 2014 at 8​:16 AM\, H.Merijn Brand \h\.m\.brand@​xs4all\.nl wrote​:

I agree with Abigail that this could be nominated to one of the worst warnings ever added to perl.

In *my* perception the warning is the wrong way round.

C\<\< print( ($x+2)*5 ); >> should warn???

You probably mean that C\<\< print ($x+2)*5; >> should mean C\<\< print +($x+2)*5; >>\, but removing the warning won't do that.

Just remove the warning completely.

We use to get lots of questions about print print the wrong stuff. We don't anymore. The warning is doing its job\, and removing it won't do anyone any good.

[p5pRT]

From @tux

On Sun\, 29 Jun 2014 13​:28​:32 -0400\, Eric Brine \ikegami@&#8203;adaelis\.com wrote​:

On Sun\, Jun 29\, 2014 at 8​:16 AM\, H.Merijn Brand \h\.m\.brand@&#8203;xs4all\.nl wrote​:

I agree with Abigail that this could be nominated to one of the worst warnings ever added to perl.

In *my* perception the warning is the wrong way round.

C\<\< print( ($x+2)*5 ); >> should warn???

*my* preference for writing functions is to put a space between the function name and the opening paren. Any other format is in *my* perception ugly and not logical.

Good​: print (($x + 2) * 5); Bad​: print( ( $x+2 )*5 );

Feel free to disagree.

That is part of the beauty of the language perl​: it allows us to create art in the way the programmer thinks it is most logical and/or beautiful.

$x++ if $a; $a and $x++;

are exactly the same in the code\, but part of us prefer the first in reading\, part of us prefer the second.

You probably mean that C\<\< print ($x+2)*5; >> should mean C\<\< print +($x+2)*5; >>\, but removing the warning won't do that.

Just remove the warning completely.

We use to get lots of questions about print print the wrong stuff. We don't anymore. The warning is doing its job\, and removing it won't do anyone any good.

It *never* warned me about what its warning is written for.

-- H.Merijn Brand http​://tux.nl Perl Monger http​://amsterdam.pm.org/ using perl5.00307 .. 5.19 porting perl5 on HP-UX\, AIX\, and openSUSE http​://mirrors.develooper.com/hpux/ http​://www.test-smoke.org/ http​://qa.perl.org http​://www.goldmark.org/jeff/stupid-disclaimers/

[p5pRT]

From @avar

It wasn't a useful warning for you. But I think it's useful to step back and think about what's useful to the average user of Perl. None of us are that guy\, we all have a commit bit. These warnings aren't for us. We already know the ins and outs of Perl.

I'm not saying we should keep this particular warning or any other warning. I'm just saying that arguing that we should or should not keep a warning is an inherent fallacy. We are not the users of these warning\, less clueful people are. How can we make Perl more useful for them? On 29 Jun 2014 20​:02\, "H.Merijn Brand" \h\.m\.brand@&#8203;xs4all\.nl wrote​:

On Sun\, 29 Jun 2014 13​:28​:32 -0400\, Eric Brine \ikegami@&#8203;adaelis\.com wrote​:

On Sun\, Jun 29\, 2014 at 8​:16 AM\, H.Merijn Brand \h\.m\.brand@&#8203;xs4all\.nl wrote​:

I agree with Abigail that this could be nominated to one of the worst warnings ever added to perl.

In *my* perception the warning is the wrong way round.

C\<\< print( ($x+2)*5 ); >> should warn???

*my* preference for writing functions is to put a space between the function name and the opening paren. Any other format is in *my* perception ugly and not logical.

Good​: print (($x + 2) * 5); Bad​: print( ( $x+2 )*5 );

Feel free to disagree.

That is part of the beauty of the language perl​: it allows us to create art in the way the programmer thinks it is most logical and/or beautiful.

$x++ if $a; $a and $x++;

are exactly the same in the code\, but part of us prefer the first in reading\, part of us prefer the second.

You probably mean that C\<\< print ($x+2)*5; >> should mean C\<\< print +($x+2)*5; >>\, but removing the warning won't do that.

Just remove the warning completely.

We use to get lots of questions about print print the wrong stuff. We don't anymore. The warning is doing its job\, and removing it won't do anyone any good.

It *never* warned me about what its warning is written for.

-- H.Merijn Brand http​://tux.nl Perl Monger http​://amsterdam.pm.org/ using perl5.00307 .. 5.19 porting perl5 on HP-UX\, AIX\, and openSUSE http​://mirrors.develooper.com/hpux/ http​://www.test-smoke.org/ http​://qa.perl.org http​://www.goldmark.org/jeff/stupid-disclaimers/

[p5pRT]

From @avar

I meant that "arguing on the basis of our own personal preference is an inherent fallacy". I.e. how can we find out what's useful for the greatest number of Perl users.

Can't we all agree that that's what we're ultimately aiming for? On 29 Jun 2014 22​:26\, "Ævar Arnfjörð Bjarmason via RT" \< perlbug-followup@​perl.org> wrote​:

It wasn't a useful warning for you. But I think it's useful to step back and think about what's useful to the average user of Perl. None of us are that guy\, we all have a commit bit. These warnings aren't for us. We already know the ins and outs of Perl.

I'm not saying we should keep this particular warning or any other warning. I'm just saying that arguing that we should or should not keep a warning is an inherent fallacy. We are not the users of these warning\, less clueful people are. How can we make Perl more useful for them? On 29 Jun 2014 20​:02\, "H.Merijn Brand" \h\.m\.brand@&#8203;xs4all\.nl wrote​:

On Sun\, 29 Jun 2014 13​:28​:32 -0400\, Eric Brine \ikegami@&#8203;adaelis\.com wrote​:

On Sun\, Jun 29\, 2014 at 8​:16 AM\, H.Merijn Brand \h\.m\.brand@&#8203;xs4all\.nl wrote​:

I agree with Abigail that this could be nominated to one of the worst warnings ever added to perl.

In *my* perception the warning is the wrong way round.

C\<\< print( ($x+2)*5 ); >> should warn???

*my* preference for writing functions is to put a space between the function name and the opening paren. Any other format is in *my* perception ugly and not logical.

Good​: print (($x + 2) * 5); Bad​: print( ( $x+2 )*5 );

Feel free to disagree.

That is part of the beauty of the language perl​: it allows us to create art in the way the programmer thinks it is most logical and/or beautiful.

$x++ if $a; $a and $x++;

are exactly the same in the code\, but part of us prefer the first in reading\, part of us prefer the second.

You probably mean that C\<\< print ($x+2)*5; >> should mean C\<\< print +($x+2)*5; >>\, but removing the warning won't do that.

Just remove the warning completely.

We use to get lots of questions about print print the wrong stuff. We don't anymore. The warning is doing its job\, and removing it won't do anyone any good.

It *never* warned me about what its warning is written for.

-- H.Merijn Brand http​://tux.nl Perl Monger http​://amsterdam.pm.org/ using perl5.00307 .. 5.19 porting perl5 on HP-UX\, AIX\, and openSUSE http​://mirrors.develooper.com/hpux/ http​://www.test-smoke.org/ http​://qa.perl.org http​://www.goldmark.org/jeff/stupid-disclaimers/

[p5pRT]

From @tux

On Sun\, 29 Jun 2014 22​:31​:04 +0200\, Ævar Arnfjörð Bjarmason \avar@&#8203;cpan\.org wrote​:

I meant that "arguing on the basis of our own personal preference is an inherent fallacy".

That is why I gave a counter-example for each of my reasonings

I am well aware that Abigail and I are in the minority in this specific case\, but we probably represent quite a number of other perl users (still a minority) that also write their code like this and are not pleased with these useless (and wrong) warning.

Keep that in mind when we *extend* the scope of a warning.

I.e. how can we find out what's useful for the greatest number of Perl users.

Wrong! That is where perl6 might have lost quite a number of good perl programmers\, amongst them Abigail and me.

This is not that I say perl6 is not a good language. I see more and more proof that it is or will be very useful in the (near) future\, but the fact that they stole my space is *the* (single) reason that I will not program in perl6. Do not underestimate the artistic feeling of perl programmers.

Can't we all agree that that's what we're ultimately aiming for?

On 29 Jun 2014 22​:26\, "Ævar Arnfjörð Bjarmason via RT" \perlbug\-followup@&#8203;perl\.org wrote​:

It wasn't a useful warning for you. But I think it's useful to step back and think about what's useful to the average user of Perl. None of us are that guy\, we all have a commit bit. These warnings aren't for us. We already know the ins and outs of Perl.

I'm not saying we should keep this particular warning or any other warning. I'm just saying that arguing that we should or should not keep a warning is an inherent fallacy. We are not the users of these warning\, less clueful people are. How can we make Perl more useful for them? On 29 Jun 2014 20​:02\, "H.Merijn Brand" \h\.m\.brand@&#8203;xs4all\.nl wrote​:

On Sun\, 29 Jun 2014 13​:28​:32 -0400\, Eric Brine \ikegami@&#8203;adaelis\.com wrote​:

On Sun\, Jun 29\, 2014 at 8​:16 AM\, H.Merijn Brand \h\.m\.brand@&#8203;xs4all\.nl wrote​:

I agree with Abigail that this could be nominated to one of the worst warnings ever added to perl.

In *my* perception the warning is the wrong way round.

C\<\< print( ($x+2)*5 ); >> should warn???

*my* preference for writing functions is to put a space between the function name and the opening paren. Any other format is in *my* perception ugly and not logical.

Good​: print (($x + 2) * 5); Bad​: print( ( $x+2 )*5 );

Feel free to disagree.

That is part of the beauty of the language perl​: it allows us to create art in the way the programmer thinks it is most logical and/or beautiful.

$x++ if $a; $a and $x++;

are exactly the same in the code\, but part of us prefer the first in reading\, part of us prefer the second.

You probably mean that C\<\< print ($x+2)*5; >> should mean C\<\< print +($x+2)*5; >>\, but removing the warning won't do that.

Just remove the warning completely.

We use to get lots of questions about print print the wrong stuff. We don't anymore. The warning is doing its job\, and removing it won't do anyone any good.

It *never* warned me about what its warning is written for.

-- H.Merijn Brand http​://tux.nl Perl Monger http​://amsterdam.pm.org/ using perl5.00307 .. 5.19 porting perl5 on HP-UX\, AIX\, and openSUSE http​://mirrors.develooper.com/hpux/ http​://www.test-smoke.org/ http​://qa.perl.org http​://www.goldmark.org/jeff/stupid-disclaimers/

[p5pRT]

From @demerphq

On 29 June 2014 22​:26\, Ævar Arnfjörð Bjarmason \avarab@&#8203;gmail\.com wrote​:

It wasn't a useful warning for you. But I think it's useful to step back and think about what's useful to the average user of Perl. None of us are that guy\, we all have a commit bit. These warnings aren't for us. We already know the ins and outs of Perl.

I'm not saying we should keep this particular warning or any other warning. I'm just saying that arguing that we should or should not keep a warning is an inherent fallacy. We are not the users of these warning\, less clueful people are. How can we make Perl more useful for them?

Personally I think this is the wrong debate.

For me the way this warning is implemented is just wrong. As implemented I would say we are better off without it than with it.

Were it to be implemented at a different level\, when the user really did something wrong\, then I would be fine with it.

It reminds me of the old broken way we used to detect special cases in split //. Eventually we started examining the regex optree and got rid of the stupid heuristics.

Yves

[p5pRT]

From @cpansprout

On Mon Jun 30 00​:07​:08 2014\, demerphq wrote​:

On 29 June 2014 22​:26\, Ævar Arnfjörð Bjarmason \avarab@&#8203;gmail\.com wrote​:

It wasn't a useful warning for you. But I think it's useful to step back and think about what's useful to the average user of Perl. None of us are that guy\, we all have a commit bit. These warnings aren't for us. We already know the ins and outs of Perl.

I'm not saying we should keep this particular warning or any other warning. I'm just saying that arguing that we should or should not keep a warning is an inherent fallacy. We are not the users of these warning\, less clueful people are. How can we make Perl more useful for them?

Personally I think this is the wrong debate.

For me the way this warning is implemented is just wrong. As implemented I would say we are better off without it than with it.

Were it to be implemented at a different level\, when the user really did something wrong\, then I would be fine with it.

Like OP_PRINT and a number being both children of a binop?

I wonder​: Why don’t void warnings already catch most of these cases? Or do they?

It reminds me of the old broken way we used to detect special cases in split //. Eventually we started examining the regex optree and got rid of the stupid heuristics.

Yves

Heh. This reminds me of​:

$ perl -le 'my $a; sort @​t; $a + $cmp;' Can't use "my $a" in sort comparison at -e line 1.

:-)

--

Father Chrysostomos