Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sys::Hostname::hostname warn on spurious arguments #14662

Closed
p5pRT opened this issue Apr 20, 2015 · 31 comments
Closed

Sys::Hostname::hostname warn on spurious arguments #14662

p5pRT opened this issue Apr 20, 2015 · 31 comments

Comments

@p5pRT
Copy link
Collaborator

@p5pRT p5pRT commented Apr 20, 2015

Migrated from rt.perl.org#124349 (status was 'resolved')

Searchable as RT124349$

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Apr 20, 2015

From @epa

Created by @epa

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.

Perl Info

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


______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Apr 20, 2015

From zefram@fysh.org

Ed Avis wrote​:

hostname() should issue a warning if arguments are provided,

It should throw an exception.

-zefram

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Apr 20, 2015

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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Apr 20, 2015

From @epa

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>

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http​://www.symanteccloud.com
______________________________________________________________________

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented May 26, 2015

From @rjbs

On Mon Apr 20 03​:46​:25 2015, eda@​waniasset.com wrote​:

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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 17, 2015

From @tonycoz

On Tue May 26 05​:08​:09 2015, rjbs wrote​:

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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 17, 2015

From @tonycoz

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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 17, 2015

From @epa

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.

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 17, 2015

From @tonycoz

On Tue Nov 17 02​:19​:04 2015, ed wrote​:

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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 17, 2015

From @ap

* 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.

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 18, 2015

From @epa

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.

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 18, 2015

From @ap

* Ed Avis via RT <perlbug-followup@​perl.org> [2015-11-18 15​:30]​:

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​:

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.

So rjbs's patch looks good.

That was Tony Cook’s patch. :-)

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 19, 2015

From @rjbs

* Aristotle Pagaltzis <pagaltzis@​gmx.de> [2015-11-17T14​:24​:37]

* 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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 19, 2015

From @tonycoz

On Wed, Nov 18, 2015 at 10​:30​:01PM -0500, Ricardo Signes wrote​:

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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 19, 2015

From zefram@fysh.org

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.

If, contrary to this opinion, we don't actually deprecate the erroneous
situation, then I take no position on whether it should warn.

-zefram

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 19, 2015

From @demerphq

On 19 November 2015 at 04​:47, Zefram <zefram@​fysh.org> wrote​:

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/"

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 19, 2015

From @epa

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.

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 19, 2015

From @Abigail

On Thu, Nov 19, 2015 at 01​:56​:47AM -0800, Ed Avis via RT wrote​:

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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 19, 2015

From zefram@fysh.org

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. 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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 20, 2015

From @ap

* Zefram <zefram@​fysh.org> [2015-11-19 12​:35]​:

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.

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.)

That it does anything other than signal an error is an accident of
implementation.

That is a correct red herring.

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 20, 2015

From zefram@fysh.org

Aristotle Pagaltzis wrote​:

* 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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Nov 21, 2015

From @rjbs

* Ricardo Signes <perl.p5p@​rjbs.manxome.org> [2015-11-18T22​:30​:01]

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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 9, 2017

From @epa

Could this bug be revisited? There was a consensus that one way or another, hostname() should start to warn when passed arguments.

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Oct 16, 2017

From @tonycoz

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 f6d7499.

Tony

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Oct 24, 2017

From @khwilliamson

On Sun, 15 Oct 2017 21​:45​:11 -0700, tonyc wrote​:

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 f6d7499.

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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 5, 2017

From zefram@fysh.org

Karl Williamson via RT wrote​:

Should this go into perldeprecation?

Yes.

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

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 6, 2017

From @xsawyerx

On 12/05/2017 08​:37 PM, Zefram wrote​:

Karl Williamson via RT wrote​:

Should this go into perldeprecation?
Yes.

Yes.

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.

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 6, 2017

From zefram@fysh.org

Deprecation dated and documented in commit
0c9c439.

-zefram

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Dec 11, 2017

@xsawyerx - Status changed from 'open' to 'pending release'

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 23, 2018

From @khwilliamson

Thank you for filing this report. You have helped make Perl better.

With the release yesterday of Perl 5.28.0, this and 185 other issues have been
resolved.

Perl 5.28.0 may be downloaded via​:
https://metacpan.org/release/XSAWYERX/perl-5.28.0

If you find that the problem persists, feel free to reopen this ticket.

@p5pRT
Copy link
Collaborator Author

@p5pRT p5pRT commented Jun 23, 2018

@khwilliamson - Status changed from 'pending release' to 'resolved'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.