Bug#931418: closed by Niko Tyni (Re: Bug#931418: perl: no errors with strict subs and bareword following a minus operator)

[Vincent Lefevre]

On 2020-05-31 15:45:11 +, Debian Bug Tracking System wrote:
> Unary plus has no effect, so the result is a bareword that is illegal
> under "strict subs".  Unary minus turns the bareword into a string with
> "-" prepended.  This is no longer a bareword, and hence legal under
> "strict subs".

As I understand it, since this is described in the perlop(1) man page,
this operation is done at execution time, like the other operations.
Thus at compilation time (where "strict subs" takes effect), it should
still be a bareword. Anyway, even if the transformation is done at
compilation time, there was first a bareword...

> Programming Perl: 3rd Edition also has mentions it. On page 92:
> 
>   One effect of these rules is that -bareword is equivalent to
>   "-bareword".  This is most useful to Tk programmers.

But "strict subs" changes the default behavior by forbidding some
constructs (at compilation time).

> I think it's clear that this is not a bug and is not going to change.
> Feel free to take it up upstream if you disagree.

As I disagree, I've reported the bug upstream:

  https://github.com/Perl/perl5/issues/17822

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#931418: perl: no errors with strict subs and bareword following a minus operator

[Vincent Lefevre]

On 2019-07-04 16:57:22 +0300, Niko Tyni wrote:
> and the following passage in perlop:
> 
> Unary "-" performs arithmetic negation if the operand is numeric,
> including any string that looks like a number. If the operand is an
> identifier, a string consisting of a minus sign concatenated with
> the identifier is returned.
> 
> So it looks like this is intentional or at least documented
> behaviour that we're stuck with.

No, that's just the default behavior, without strict subs.
Similarly, the perlop(1) man page says:

  Unary "+" has no effect whatsoever, even on strings. [...]

Thus:

zira:~> perl -e 'my $x = -Inf; print "$x\n";'
-Inf
zira:~> perl -e 'my $x = +Inf; print "$x\n";'
Inf

as documented. But with "use strict;", the one with +Inf gives
an error, but not the one with -Inf.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#931418: perl: no errors with strict subs and bareword following a minus operator

[Niko Tyni]

On Thu, Jul 04, 2019 at 02:10:22PM +0200, Vincent Lefevre wrote:
> Package: perl
> Version: 5.28.1-6
> Severity: normal
> 
> The following does no yield any error:
> 
>   perl -e 'use strict; my $x = - Inf;'
> 
> This does not seem to be intended.

Inf is not special here, other strings behave similarly.

Googling a bit turns up

 
https://stackoverflow.com/questions/23215511/ambiguous-use-of-constant-resolved-as-constant

 https://www.perlmonks.org/?node_id=1047125

and the following passage in perlop:

Unary "-" performs arithmetic negation if the operand is numeric,
including any string that looks like a number. If the operand is an
identifier, a string consisting of a minus sign concatenated with
the identifier is returned.

So it looks like this is intentional or at least documented
behaviour that we're stuck with.
-- 
Niko Tyni   nt...@debian.org

Bug#931418: perl: no errors with strict subs and bareword following a minus operator

[Vincent Lefevre]

Package: perl
Version: 5.28.1-6
Severity: normal

The following does no yield any error:

  perl -e 'use strict; my $x = - Inf;'

This does not seem to be intended.

The strict(3perl) man page says:

"strict subs"
  This disables the poetry optimization, generating a compile-time
  error if you try to use a bareword identifier that's not a
  subroutine, unless it is a simple identifier (no colons) and that
  it appears in curly braces or on the left hand side of the "=>"
  symbol.

  use strict 'subs';
  $SIG{PIPE} = Plumber;   # blows up
  $SIG{PIPE} = "Plumber"; # fine: quoted string is always ok
  $SIG{PIPE} = \&Plumber; # preferred form

and the perldata(1) man page says:

Some people may wish to outlaw barewords entirely.  If you say

use strict 'subs';

then any bareword that would NOT be interpreted as a subroutine call
produces a compile-time error instead.  [...]

There does not seem to be an exception after a minus operator.

-- System Information:
Debian Release: 10.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages perl depends on:
ii  dpkg   1.19.7
ii  libperl5.285.28.1-6
ii  perl-base  5.28.1-6
ii  perl-modules-5.28  5.28.1-6

Versions of packages perl recommends:
ii  netbase  5.6

Versions of packages perl suggests:
pn  libb-debug-perl 
pn  liblocale-codes-perl
pn  libterm-readline-gnu-perl | libterm-readline-perl-perl  
ii  make4.2.1-1.2
ii  perl-doc5.28.1-6

-- no debconf information