Skip Menu |
Report information
Id: 124349
Status: pending release
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: eda [at] waniasset.com
Cc:
AdminCc:

Operating System: Linux
PatchStatus: (no value)
Severity: low
Type: library
Perl Version: 5.18.4
Fixed In: 5.27.7



To: "'perlbug [...] perl.org'" <perlbug [...] perl.org>
Date: Mon, 20 Apr 2015 10:35:11 +0000
From: Ed Avis <eda [...] waniasset.com>
Subject: Sys::Hostname::hostname warn on spurious arguments
Download (untitled) / with headers
text/plain 6.5k
This is a bug report for perl from eda@waniasset.com, generated with the help of perlbug 1.39 running under perl 5.18.4. ----------------------------------------------------------------- [Please describe your issue here] Sys::Hostname::hostname takes no arguments. But it silently ignores any bogus arguments which are passed. This can cause mistaken usages of hostname() to creep into code unnoticed. I found calls to hostname('some-host'), probably a mistaken attempt to get a canonical hostname, and even hostname($<), where I have no idea what the programmer thought was happening. hostname() should issue a warning if arguments are provided, since they can do no good. [Please do not change anything below this line] ----------------------------------------------------------------- --- Flags: category=library severity=low module=Sys::Hostname --- Site configuration information for perl 5.18.4: Configured by Red Hat, Inc. at Fri Feb 13 16:10:58 UTC 2015. Summary of my perl5 (revision 5 version 18 subversion 4) configuration: Platform: osname=linux, osvers=3.18.5-201.fc21.x86_64, archname=x86_64-linux-thread-multi uname='linux buildvm-09.phx2.fedoraproject.org 3.18.5-201.fc21.x86_64 #1 smp mon feb 2 21:00:58 utc 2015 x86_64 x86_64 x86_64 gnulinux ' config_args='-des -Doptimize=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -Dccdlflags=-Wl,--enable-new-dtags -Dlddlflags=-shared -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -Wl,-z,relro -Dshrpdir=/usr/lib64 -DDEBUGGING=-g -Dversion=5.18.4 -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dprefix=/usr -Dvendorprefix=/usr -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl5 -Dsitearch=/usr/local/lib64/perl5 -Dprivlib=/usr/share/perl5 -Dvendorlib=/usr/share/perl5/vendor_perl -Darchlib=/usr/lib64/perl5 -Dvendorarch=/usr/lib64/perl5/vendor_perl -Darchname=x86_64-linux-thread-multi -Dlibpth=/usr/local/lib64 /lib64 /usr/lib64 -Duseshrplib -Dusethreads -Duseithreads -Dusedtrace=/usr/bin/dtrace -Duselargefiles -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto -Ud_sethostent_r_proto -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto -Ud_endservent_r_proto -Ud_setservent_r_proto -Dscriptdir=/usr/bin -Dusesitecustomize' hint=recommended, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic', cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include' ccversion='', gccversion='4.8.3 20140911 (Red Hat 4.8.3-7)', 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='gcc', ldflags =' -fstack-protector' libpth=/usr/local/lib64 /lib64 /usr/lib64 libs=-lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc -lgdbm_compat perllibs=-lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc libc=, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='2.18' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,--enable-new-dtags' cccdlflags='-fPIC', lddlflags='-shared -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -Wl,-z,relro ' Locally applied patches: Fedora Patch1: Removes date check, Fedora/RHEL specific Fedora Patch3: support for libdir64 Fedora Patch4: use libresolv instead of libbind Fedora Patch5: USE_MM_LD_RUN_PATH Fedora Patch6: Skip hostname tests, due to builders not being network capable Fedora Patch7: Dont run one io test due to random builder failures Fedora Patch9: Fix find2perl to translate ? glob properly (RT#113054) Fedora Patch10: Update h2ph(1) documentation (RT#117647) Fedora Patch11: Update pod2html(1) documentation (RT#117623) Fedora Patch12: Disable ornaments on perl5db AutoTrace tests (RT#118817) Fedora Patch14: Do not use system Term::ReadLine::Gnu in tests (RT#118821) Fedora Patch15: Define SONAME for libperl.so Fedora Patch16: Install libperl.so to -Dshrpdir value Fedora Patch18: Fix crash with \\&$glob_copy (RT#119051) Fedora Patch19: Fix coreamp.t rand test (RT#118237) Fedora Patch20: Reap child in case where exception has been thrown (RT#114722) Fedora Patch21: Fix using regular expressions containing multiple code blocks (RT#117917) Fedora Patch22: Create site paths by cpan for the first time (CPAN RT#99905) Fedora Patch200: Link XS modules to libperl.so with EU::CBuilder on Linux Fedora Patch201: Link XS modules to libperl.so with EU::MM on Linux --- @INC for perl 5.18.4: /home/eda/lib/perl5/ /home/eda/lib64/perl5/ /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 . --- Environment for perl 5.18.4: HOME=/home/eda LANG=en_GB.UTF-8 LANGUAGE (unset) LC_COLLATE=C LC_CTYPE=en_GB.UTF-8 LC_MESSAGES=en_GB.UTF-8 LC_MONETARY=en_GB.UTF-8 LC_NUMERIC=en_GB.UTF-8 LC_TIME=en_GB.UTF-8 LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/home/eda/bin:/home/eda/bin:/usr/local/bin:/usr/bin:/sbin:/usr/sbin:/sbin:/usr/sbin PERL5LIB=/home/eda/lib/perl5/:/home/eda/lib64/perl5/ PERL_BADLANG (unset) SHELL=/bin/bash Show quoted text
______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com
______________________________________________________________________
Date: Mon, 20 Apr 2015 11:43:34 +0100
From: Zefram <zefram [...] fysh.org>
To: perl5-porters [...] perl.org
Subject: Re: [perl #124349] Sys::Hostname::hostname warn on spurious arguments
Download (untitled) / with headers
text/plain 118b
Ed Avis wrote: Show quoted text
>hostname() should issue a warning if arguments are provided,
It should throw an exception. -zefram
From: Ed Avis <eda [...] waniasset.com>
Subject: RE: [perl #124349] Sys::Hostname::hostname warn on spurious arguments
To: "'perlbug-followup [...] perl.org'" <perlbug-followup [...] perl.org>
Date: Mon, 20 Apr 2015 10:45:43 +0000
Download (untitled) / with headers
text/plain 758b
I agree, it should throw an exception. I proposed the more timid alternative of just warning because I know that if it started throwing exceptions, existing and "working" code would break. So I imagined the cautious way forward was to warn for a release or two and start throwing exceptions at some point in the future. If the p5-porters are happy to take the bold approach of just dying on any argument passed to hostname(), I am all for it. -- Ed Avis <eda@waniasset.com> Show quoted text
______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com
______________________________________________________________________
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 744b
On Mon Apr 20 03:46:25 2015, eda@waniasset.com wrote: Show quoted text
> I agree, it should throw an exception. > > I proposed the more timid alternative of just warning because I know > that if it started throwing exceptions, existing and "working" code > would break. > So I imagined the cautious way forward was to warn for a release or > two and start throwing exceptions at some point in the future. > > If the p5-porters are happy to take the bold approach of just dying on > any argument passed to hostname(), I am all for it.
I'd be okay with just making it fatal, but I don't think it's in line with policy, and I don't think it's worth an exception. Care to provide a patch that issues a deprecation-category warning on args to hostname? -- rjbs
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 294b
On Tue May 26 05:08:09 2015, rjbs wrote: Show quoted text
> I'd be okay with just making it fatal, but I don't think it's in line > with policy, and I don't think it's worth an exception. Care to > provide a patch that issues a deprecation-category warning on args to > hostname?
How about the attached? Tony
Subject: 0001-perl-124349-deprecation-warning-on-hostname-with-arg.patch
From dfb56efaaf66c156f4025ae1f0bc34b00596d441 Mon Sep 17 00:00:00 2001 From: Tony Cook <tony@develop-help.com> Date: Tue, 17 Nov 2015 11:56:12 +1100 Subject: [perl #124349] deprecation warning on hostname() with arguments --- ext/Sys-Hostname/Hostname.pm | 5 ++++- ext/Sys-Hostname/t/Hostname.t | 32 +++++++++++++++++++++++--------- 2 files changed, 27 insertions(+), 10 deletions(-) diff --git a/ext/Sys-Hostname/Hostname.pm b/ext/Sys-Hostname/Hostname.pm index 42e9293..d53410e 100644 --- a/ext/Sys-Hostname/Hostname.pm +++ b/ext/Sys-Hostname/Hostname.pm @@ -11,10 +11,12 @@ our @EXPORT = qw/ hostname /; our $VERSION; +use warnings (); + our $host; BEGIN { - $VERSION = '1.20'; + $VERSION = '1.21'; { local $SIG{__DIE__}; eval { @@ -27,6 +29,7 @@ BEGIN { sub hostname { + @_ and warnings::warnif("deprecated", "hostname() doesn't accept any arguments"); # method 1 - we already know it return $host if defined $host; diff --git a/ext/Sys-Hostname/t/Hostname.t b/ext/Sys-Hostname/t/Hostname.t index 40352ba..a8c259d 100644 --- a/ext/Sys-Hostname/t/Hostname.t +++ b/ext/Sys-Hostname/t/Hostname.t @@ -10,14 +10,28 @@ BEGIN { use Sys::Hostname; -eval { - $host = hostname; -}; +use Test::More tests => 4; -if ($@) { - print "1..0\n" if $@ =~ /Cannot get host name/; -} else { - print "1..1\n"; - print "# \$host = '$host'\n"; - print "ok 1\n"; +SKIP: +{ + eval { + $host = hostname; + }; + skip "No hostname available", 1 + if $@ =~ /Cannot get host name/; + isnt($host, undef, "got a hostname"); +} + +{ + use warnings; + my $warn; + local $SIG{__WARN__} = sub { $warn = "@_" }; + eval { hostname("dummy") }; + ok($warn, "warns with an argument"); + like($warn, qr/hostname\(\) doesn't accept any arguments/, + "appropriate message"); + no warnings "deprecated"; + undef $warn; + eval { hostname("dummy") }; + is($warn, undef, "no warning when disabled"); } -- 2.1.4
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 503b
Thanks for writing the patch. Are we sure that 'deprecated' is an appropriate warnings category? This is not a case of some existing feature which is scheduled to go away in the future. Arguments to hostname() have never done anything, now or in the past. Even if you don't care about making your code compatible with some future version of perl (which is the purpose of deprecation warnings) you would probably still want to find out about confused code which calls hostname with useless arguments.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 626b
On Tue Nov 17 02:19:04 2015, ed wrote: Show quoted text
> Thanks for writing the patch. Are we sure that 'deprecated' is an > appropriate warnings category? This is not a case of some existing > feature which is scheduled to go away in the future. Arguments to > hostname() have never done anything, now or in the past. Even if you > don't care about making your code compatible with some future version > of perl (which is the purpose of deprecation warnings) you would > probably still want to find out about confused code which calls > hostname with useless arguments.
I have no particular preference: it's what rjbs asked for. Tony
Date: Tue, 17 Nov 2015 20:24:37 +0100
Subject: Re: [perl #124349] Sys::Hostname::hostname warn on spurious arguments
To: perl5-porters [...] perl.org
From: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
Download (untitled) / with headers
text/plain 450b
* Ed Avis via RT <perlbug-followup@perl.org> [2015-11-17 11:20]: Show quoted text
> This is not a case of some existing feature which is scheduled to go > away in the future.
Yes it is – assuming I read rjbs’ quite implicit comment correctly. He said he wouldn’t mind making this croak but it would contradict policy to do so immediately, so he asked it to be given a deprecation warning. I understood this to mean that he intends for it to croak eventually.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 192b
Thanks for your views. The question of which exact warning category to use can get a bit rabbinical. The important thing is that there be a warning of some kind. So rjbs's patch looks good.
To: perl5-porters [...] perl.org
From: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
Subject: Re: [perl #124349] Sys::Hostname::hostname warn on spurious arguments
Date: Thu, 19 Nov 2015 00:58:47 +0100
Download (untitled) / with headers
text/plain 432b
* Ed Avis via RT <perlbug-followup@perl.org> [2015-11-18 15:30]: Show quoted text
> Thanks for your views. The question of which exact warning category to > use can get a bit rabbinical.
Maybe so; but not in this case: Show quoted text
> The important thing is that there be a warning of some kind.
There is going to be not just a warning, but an exception. The warning is just an interim state. Show quoted text
> So rjbs's patch looks good.
That was Tony Cook’s patch. :-)
To: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
CC: perl5-porters [...] perl.org
Subject: Re: [perl #124349] Sys::Hostname::hostname warn on spurious arguments
From: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
Date: Wed, 18 Nov 2015 22:30:01 -0500
Download (untitled) / with headers
text/plain 1.9k
* Aristotle Pagaltzis <pagaltzis@gmx.de> [2015-11-17T14:24:37] Show quoted text
> * Ed Avis via RT <perlbug-followup@perl.org> [2015-11-17 11:20]:
> > This is not a case of some existing feature which is scheduled to go > > away in the future.
> > Yes it is – assuming I read rjbs’ quite implicit comment correctly. He > said he wouldn’t mind making this croak but it would contradict policy > to do so immediately, so he asked it to be given a deprecation warning. > I understood this to mean that he intends for it to croak eventually.
I believe that's what I meant at the time. I am now second-guessing. Here's our recently-revised perlpolicy on when we deprecate: Existing syntax and semantics should only be marked for destruction in very limited circumstances. If they are believed to be very rarely used, stand in the way of actual improvement to the Perl language or perl interpreter, and if affected code can be easily updated to continue working, they may be considered for removal. When in doubt, caution dictates that we will favor backward compatibility. When a feature is deprecated, a statement of reasoning describing the decision process will be posted, and a link to it will be provided in the relevant perldelta documents. You can read the behavior as "standing in the way of improvement" through a sort of sideways circular argument, but I'm not enthused by that. I think our options are at least these: 1 do nothing 2 deprecate with an explanation not covered by the policy above 3 deprecate, claiming that the policy above covers it 4 issue an unconditional, but not-deprecation-category warning with warn 5 issue a warnings::warn and register a Sys::Hostname category Let's have a quick check in from people who have an opinion on this? I'm between #2 and #4. If we go with #4, I'll update Tony's patch and apply it, since I'm the one causing this last minute reconsideration. ;) -- rjbs
Download signature.asc
application/pgp-signature 473b

Message body not shown because it is not plain text.

Subject: Re: [perl #124349] Sys::Hostname::hostname warn on spurious arguments
Date: Thu, 19 Nov 2015 14:38:25 +1100
To: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
From: Tony Cook <tony [...] develop-help.com>
CC: Aristotle Pagaltzis <pagaltzis [...] gmx.de>, perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 879b
On Wed, Nov 18, 2015 at 10:30:01PM -0500, Ricardo Signes wrote: Show quoted text
> I think our options are at least these: > > 1 do nothing > > 2 deprecate with an explanation not covered by the policy above > > 3 deprecate, claiming that the policy above covers it > > 4 issue an unconditional, but not-deprecation-category warning with warn > > 5 issue a warnings::warn and register a Sys::Hostname category > > Let's have a quick check in from people who have an opinion on this? I'm > between #2 and #4. If we go with #4, I'll update Tony's patch and apply it, > since I'm the one causing this last minute reconsideration. ;)
Or: 6 make it croak, per the original discussion, justified as a bug fix. I don't have a strong opinion in any direction, I just bookmarked it when it was originally discussed, and implemented it as low-hanging fruit :) Tony
Subject: Re: [perl #124349] Sys::Hostname::hostname warn on spurious arguments
Date: Thu, 19 Nov 2015 03:47:38 +0000
To: perl5-porters [...] perl.org
From: Zefram <zefram [...] fysh.org>
Download (untitled) / with headers
text/plain 913b
Ricardo Signes wrote: Show quoted text
> 2 deprecate with an explanation not covered by the policy above
I think this is appropriate. The deprecation policy that you quoted is aimed at core semantics, and doesn't take into account the rather different range of situations that arise in features presented as subroutines in modules. I think the lack of a check for incorrectly-formed argument lists is a flaw in the subroutine, the callers passing non-empty argument lists are clearly in error, and we're generally free to start detecting these errors. Because of the wide use of Sys::Hostname due to its distribution with the core, and because of the resultant tying of it to the core version, it's wise to use a deprecation cycle rather than just add the error check outright. If, contrary to this opinion, we don't actually deprecate the erroneous situation, then I take no position on whether it should warn. -zefram
Subject: Re: [perl #124349] Sys::Hostname::hostname warn on spurious arguments
Date: Thu, 19 Nov 2015 10:19:16 +0100
From: demerphq <demerphq [...] gmail.com>
To: Zefram <zefram [...] fysh.org>
CC: Perl5 Porteros <perl5-porters [...] perl.org>
On 19 November 2015 at 04:47, Zefram <zefram@fysh.org> wrote: Show quoted text
> Ricardo Signes wrote:
>> 2 deprecate with an explanation not covered by the policy above
> > I think this is appropriate. The deprecation policy that you > quoted is aimed at core semantics, and doesn't take into account > the rather different range of situations that arise in features > presented as subroutines in modules. I think the lack of a check > for incorrectly-formed argument lists is a flaw in the subroutine, > the callers passing non-empty argument lists are clearly in error, > and we're generally free to start detecting these errors. Because of > the wide use of Sys::Hostname due to its distribution with the core, > and because of the resultant tying of it to the core version, it's wise > to use a deprecation cycle rather than just add the error check outright.
I agree. Were Sys::Hostname a cpan module I think there would be little controversy about making this an error outright, because it is core, doing so via a deprecation cycle seems reasonable. Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.3k
The text about deprecation talks about 'existing syntax and semantics' but this is vague. By some definition any language behaviour including the most horrible bug is 'existing semantics' and any construct written in a current Perl program is 'existing syntax'. I think it would be better for the deprecation policy to make it clear that it applies to existing *documented* behaviour or to that which, although not explicitly documented, is widely and deliberately used. On the other hand if 'deprecation' includes any kind of warning which may later become a fatal error, that could be made clear too. Another way to look at it is that deprecation covers things which are a working part of the language today, but will be withdrawn in a future version. If you don't care about future versions you could turn off deprecation warnings. But even in that case you would probably want to find out about odd calls like hostname('x') since they are mistakes *now*, and always have been, regardless of what may happen in a future release. By contrast a true deprecation is something which is correct code today. For these reasons I felt that a non-deprecation warning was best. There is no existing language feature which is being removed; arguments to hostname have never done anything useful. But I am content with any warning category.
CC: "OtherRecipients of perl Ticket #124349": ;, perl5-porters [...] perl.org
From: Abigail <abigail [...] abigail.be>
To: Ed Avis via RT <perlbug-followup [...] perl.org>
Subject: Re: [perl #124349] Sys::Hostname::hostname warn on spurious arguments
Date: Thu, 19 Nov 2015 12:20:56 +0100
Download (untitled) / with headers
text/plain 1.7k
On Thu, Nov 19, 2015 at 01:56:47AM -0800, Ed Avis via RT wrote: Show quoted text
> The text about deprecation talks about 'existing syntax and semantics' > but this is vague. By some definition any language behaviour including > the most horrible bug is 'existing semantics' and any construct written > in a current Perl program is 'existing syntax'. I think it would be > better for the deprecation policy to make it clear that it applies to > existing *documented* behaviour or to that which, although not explicitly > documented, is widely and deliberately used. On the other hand if > 'deprecation' includes any kind of warning which may later become a > fatal error, that could be made clear too. > > Another way to look at it is that deprecation covers things which are > a working part of the language today, but will be withdrawn in a future > version. If you don't care about future versions you could turn off > deprecation warnings. But even in that case you would probably want to > find out about odd calls like hostname('x') since they are mistakes *now*, > and always have been, regardless of what may happen in a future release. > By contrast a true deprecation is something which is correct code today. > > For these reasons I felt that a non-deprecation warning was best. > There is no existing language feature which is being removed; arguments > to hostname have never done anything useful. But I am content with any > warning category.
If arguments to hostname() have never done anything useful, how could hostname('x') be a mistake? It's not that hostname('x') is returning a different value depending on whether or not it has an argument. Are there any future plans for hostname() to actually return something different if an argument is given? Abigail
Date: Thu, 19 Nov 2015 11:32:24 +0000
Subject: Re: [perl #124349] Sys::Hostname::hostname warn on spurious arguments
From: Zefram <zefram [...] fysh.org>
To: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 355b
Abigail wrote: Show quoted text
>If arguments to hostname() have never done anything useful, how could >hostname('x') be a mistake?
hostname() is documented to take no parameters. Passing any parameters is a usage that falls outside the published API, and so is never correct. That it does anything other than signal an error is an accident of implementation. -zefram
Subject: Re: [perl #124349] Sys::Hostname::hostname warn on spurious arguments
Date: Fri, 20 Nov 2015 05:28:48 +0100
To: perl5-porters [...] perl.org
From: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
Download (untitled) / with headers
text/plain 749b
* Zefram <zefram@fysh.org> [2015-11-19 12:35]: Show quoted text
> Abigail wrote:
> >If arguments to hostname() have never done anything useful, how could > >hostname('x') be a mistake?
> > hostname() is documented to take no parameters.
It is not. The documentation is mute on the subject of arguments. Show quoted text
> Passing any parameters is a usage that falls outside the published > API, and so is never correct.
It is also never incorrect. The documentation does not propose any expectation about what should happen upon passing parameters to it. (Though even if it did, the bug might be what the documentation says rather than what the code does.) Show quoted text
> That it does anything other than signal an error is an accident of > implementation.
That is a correct red herring.
To: perl5-porters [...] perl.org
From: Zefram <zefram [...] fysh.org>
Date: Fri, 20 Nov 2015 05:55:10 +0000
Subject: Re: [perl #124349] Sys::Hostname::hostname warn on spurious arguments
Download (untitled) / with headers
text/plain 525b
Aristotle Pagaltzis wrote: Show quoted text
>* Zefram <zefram@fysh.org> [2015-11-19 12:35]:
>> hostname() is documented to take no parameters.
> >It is not. The documentation is mute on the subject of arguments.
The documentation shows it called with no parameters, and does not show any other way of calling it. The "and calling it in ways not depicted is not supported" is implicit. Admittedly it could be clearer: the calling usage is shown only in the synopsis, not in an explicit representation of parameter list structure. -zefram
Subject: Re: [perl #124349] Sys::Hostname::hostname warn on spurious arguments
To: Aristotle Pagaltzis <pagaltzis [...] gmx.de>
CC: perl5-porters [...] perl.org
Date: Fri, 20 Nov 2015 21:58:04 -0500
From: Ricardo Signes <perl.p5p [...] rjbs.manxome.org>
Download (untitled) / with headers
text/plain 589b
* Ricardo Signes <perl.p5p@rjbs.manxome.org> [2015-11-18T22:30:01] Show quoted text
> > 2 deprecate with an explanation not covered by the policy above
I've given this thought and I think we should go with #2. If Sys-Hostname was an upstream-CPAN distribution, I would allow this change as a reasonable step by a module maintainer to better sanity-check inputs. Upstream-blead dists should not be treated differently from upstream-CPAN dists, because they should, generally, be switchable between upstreams as needed. We can look at adding something to perlpolicy about this, if needed. -- rjbs
Download signature.asc
application/pgp-signature 473b

Message body not shown because it is not plain text.

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 131b
Could this bug be revisited? There was a consensus that one way or another, hostname() should start to warn when passed arguments.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 255b
On Fri, 09 Jun 2017 08:57:40 -0700, ed wrote: Show quoted text
> Could this bug be revisited? There was a consensus that one way or > another, hostname() should start to warn when passed arguments.
I've applied my patch as f6d7499a254e64c1114bf95c89e5c65a22597416. Tony
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 524b
On Sun, 15 Oct 2017 21:45:11 -0700, tonyc wrote: Show quoted text
> On Fri, 09 Jun 2017 08:57:40 -0700, ed wrote:
> > Could this bug be revisited? There was a consensus that one way or > > another, hostname() should start to warn when passed arguments.
> > I've applied my patch as f6d7499a254e64c1114bf95c89e5c65a22597416. > > Tony
Should this go into perldeprecation? Somehow ISTR that deprecation messages are now supposed to include a definite deadline release in their text, but I don't see that written down -- Karl Williamson
From: Zefram <zefram [...] fysh.org>
Subject: Re: [perl #124349] Sys::Hostname::hostname warn on spurious arguments
Date: Tue, 5 Dec 2017 18:37:03 +0000
To: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 326b
Karl Williamson via RT wrote: Show quoted text
>Should this go into perldeprecation?
Yes. Show quoted text
>Somehow ISTR that deprecation messages are now supposed to include a >definite deadline
With the deprecation warning in 5.28 and 5.30, the minimum possible deadline is "will become fatal in Perl 5.32". I think we should use that deadline. -zefram
From: Sawyer X <xsawyerx [...] gmail.com>
Date: Wed, 6 Dec 2017 11:58:57 +0200
To: Zefram <zefram [...] fysh.org>, perl5-porters [...] perl.org
Subject: Re: [perl #124349] Sys::Hostname::hostname warn on spurious arguments
Download (untitled) / with headers
text/plain 388b
On 12/05/2017 08:37 PM, Zefram wrote: Show quoted text
> Karl Williamson via RT wrote:
>> Should this go into perldeprecation?
> Yes.
Yes. Show quoted text
>
>> Somehow ISTR that deprecation messages are now supposed to include a >> definite deadline
> With the deprecation warning in 5.28 and 5.30, the minimum possible > deadline is "will become fatal in Perl 5.32". I think we should use > that deadline.
Agreed.
From: Zefram <zefram [...] fysh.org>
Subject: Re: [perl #124349] Sys::Hostname::hostname warn on spurious arguments
To: perl5-porters [...] perl.org
Date: Wed, 6 Dec 2017 16:34:07 +0000
Deprecation dated and documented in commit 0c9c439d08a65206d442724bcd9fb29fa5a7f937. -zefram


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org