Your message dated Sun, 31 May 2020 18:42:25 +0300 with message-id <[email protected]> and subject line Re: Bug#931418: perl: no errors with strict subs and bareword following a minus operator has caused the Debian Bug report #931418, regarding perl: no errors with strict subs and bareword following a minus operator to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 931418: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931418 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---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.28 5.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 <none> pn liblocale-codes-perl <none> pn libterm-readline-gnu-perl | libterm-readline-perl-perl <none> ii make 4.2.1-1.2 ii perl-doc 5.28.1-6 -- no debconf information
--- End Message ---
--- Begin Message ---On Thu, Jul 04, 2019 at 05:30:00PM +0200, Vincent Lefevre wrote: > 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. 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". 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. 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. I'm closing this. -- Niko Tyni [email protected]
--- End Message ---
