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

perldoc perlvar for %! should discuss values #14929

Closed
p5pRT opened this issue Sep 25, 2015 · 22 comments
Closed

perldoc perlvar for %! should discuss values #14929

p5pRT opened this issue Sep 25, 2015 · 22 comments

Comments

@p5pRT
Copy link

p5pRT commented Sep 25, 2015

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

Searchable as RT126174$

@p5pRT
Copy link
Author

p5pRT commented Sep 25, 2015

From @FGasper

Created by @FGasper

The docs for %! in perlvar don’t discuss the actual values of %!.
I noticed recently that th values of this hash match up with the
corresponding Errno values; e.g.​:

{
  local $! = 5; #EIO on Linux
  print $!{'EIO'}; #prints 5, or Errno​::EIO().
}

The docs seem to indicate that the values of this hash, though,
are simply “truthy” or “falsey”; i.e., not to rely on them for
anything more interesting.

Is this still the case? Or, may language users depend on values of
%! to match up with the corresponding Errno.pm constants?

Some clarification in the docs would be welcome. Thank you!

Perl Info

Flags:
    category=docs
    severity=low

Site configuration information for perl 5.14.4:

Configured by cPanel at Tue Dec 16 16:26:36 CST 2014.

Summary of my perl5 (revision 5 version 14 subversion 4) configuration:
   
  Platform:
    osname=linux, osvers=2.6.32-358.23.2.el6.i686, archname=i386-linux-64int
    uname='linux rpmb-32-centos-6 2.6.32-358.23.2.el6.i686 #1 smp wed oct 16 17:21:31 utc 2013 i686 i686 i386 gnulinux '
    config_args='-des -Dusedevel -Darchname=i386-linux-64int -Dcc=/usr/bin/gcc -Dcpp=/usr/bin/cpp -DDEBUGGING=none -Doptimize=-Os -Dusemymalloc=n -Duseshrplib -Duselargefiles=yes -Duseposix=true -Dhint=recommended -Duseperlio=yes -Dccflags=-I/usr/local/cpanel/3rdparty/perl/514/include -L/usr/local/cpanel/3rdparty/perl/514/lib -I/usr/local/cpanel/3rdparty/include -L/usr/local/cpanel/3rdparty/lib -DAPPLLIB_EXP="/usr/local/cpanel" -Dcppflags=-I/usr/local/cpanel/3rdparty/perl/514/include -L/usr/local/cpanel/3rdparty/perl/514/lib -I/usr/local/cpanel/3rdparty/include -L/usr/local/cpanel/3rdparty/lib -Dldflags=-Wl,-rpath -Wl,/usr/local/cpanel/3rdparty/perl/514/lib -L/usr/local/cpanel/3rdparty/perl/514/lib -L/usr/local/cpanel/3rdparty/lib -Dprefix=/usr/local/cpanel/3rdparty/perl/514 -Dsiteprefix=/opt/cpanel/perl5/514 -Dsitebin=/opt/cpanel/perl5/514/bin -Dsitelib=/opt/cpanel/perl5/514/site_lib -Dusevendorprefix=true -Dvendorbin=/usr/local/cpanel/3rdparty/perl/514/bin -Dvendorprefix=/usr/local/cpanel/3rdparty/perl/514/lib/perl5 -Dvendorlib=/usr/local/cpanel/3rdparty/perl/514/lib/perl5/cpanel_lib -Dprivlib=/usr/local/cpanel/3rdparty/perl/514/lib/perl5/5.14.4 -Dman1dir=none -Dman3dir=none -Dscriptdir=/usr/local/cpanel/3rdparty/perl/514/bin -Dscriptdirexp=/usr/local/cpanel/3rdparty/perl/514/bin -Dsiteman1dir=none -Dsiteman3dir=none -Dinstallman1dir=none -Dversiononly=no -Dinstallusrbinperl=no -Dcf_by=cPanel -Dmyhostname=localhost -Dperladmin=root@localhost -Dcf_email=support@cpanel.net -Di_dbm=/usr/local/cpanel/3rdparty/include -Di_gdbm=/usr/local/cpanel/3rdparty/include -Di_ndbm=/usr/local/cpanel/3rdparty/include -Ud_dosuid -Uuserelocatableinc -Umad -Uusethreads -Uusemultiplicity -Uusesocks -Uuselongdouble -Ui_db -Aldflags=-L/usr/local/cpanel/3rdparty/perl/514/lib -L/usr/local/cpanel/3rdparty/lib -L/usr/lib -L/lib -lgdbm -Dlocincpth=/usr/local/cpanel/3rdparty/perl/514/include /usr/local/cpanel/3rdparty/include /usr/local/include  -Duse64bitint -Uuse64bitall -Acflags=-fPIC -DPIC -m32 -I/usr/local/cpanel/3rdparty/perl/514/include -I/usr/local/cpanel/3rdparty/include -Dlibpth=/usr/local/cpanel/3rdparty/perl/514/lib /usr/local/cpanel/3rdparty/lib /usr/local/lib /lib /usr/lib '
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=undef, usemultiplicity=undef
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=define, use64bitall=undef, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='/usr/bin/gcc', ccflags ='-I/usr/local/cpanel/3rdparty/perl/514/include -L/usr/local/cpanel/3rdparty/perl/514/lib -I/usr/local/cpanel/3rdparty/include -L/usr/local/cpanel/3rdparty/lib -DAPPLLIB_EXP="/usr/local/cpanel" -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-Os',
    cppflags='-I/usr/local/cpanel/3rdparty/perl/514/include -L/usr/local/cpanel/3rdparty/perl/514/lib -I/usr/local/cpanel/3rdparty/include -L/usr/local/cpanel/3rdparty/lib -I/usr/local/cpanel/3rdparty/perl/514/include -L/usr/local/cpanel/3rdparty/perl/514/lib -I/usr/local/cpanel/3rdparty/include -L/usr/local/cpanel/3rdparty/lib -DAPPLLIB_EXP="/usr/local/cpanel" -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
    ccversion='', gccversion='4.4.7 20120313 (Red Hat 4.4.7-3)', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='/usr/bin/gcc', ldflags ='-Wl,-rpath -Wl,/usr/local/cpanel/3rdparty/perl/514/lib -L/usr/local/cpanel/3rdparty/perl/514/lib -L/usr/local/cpanel/3rdparty/lib -L/usr/local/cpanel/3rdparty/perl/514/lib -L/usr/local/cpanel/3rdparty/lib -L/usr/lib -L/lib -lgdbm -fstack-protector -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc
    perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
    libc=/lib/libc-2.12.so, so=so, useshrplib=true, libperl=libperl.so
    gnulibc_version='2.12'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/local/cpanel/3rdparty/perl/514/lib/perl5/5.14.4/i386-linux-64int/CORE'
    cccdlflags='-fPIC', lddlflags='-shared -Os -L/usr/local/cpanel/3rdparty/perl/514/lib -L/usr/local/cpanel/3rdparty/lib -L/usr/lib -L/lib -L/usr/local/lib -fstack-protector'

Locally applied patches:
    cPanel patches
    cPanel INC path changes
    Disabled some unstable tests on a kvm build server
    Cherry pick of 49498ca from p5p (RT 113514)
    Remove improper use of each() in B::walksymtable (5cc8528c90)


@INC for perl 5.14.4:
    /usr/local/cpanel
    /usr/local/cpanel
    /usr/local/cpanel/3rdparty/perl/514/lib/perl5/cpanel_lib/i386-linux-64int
    /usr/local/cpanel/3rdparty/perl/514/lib/perl5/cpanel_lib
    /usr/local/cpanel/3rdparty/perl/514/lib/perl5/5.14.4/i386-linux-64int
    /usr/local/cpanel/3rdparty/perl/514/lib/perl5/5.14.4
    /opt/cpanel/perl5/514/site_lib/i386-linux-64int
    /opt/cpanel/perl5/514/site_lib
    .


Environment for perl 5.14.4:
    HOME=/root
    LANG=en_US.UTF-8
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/root/perl5/perlbrew/bin:/root/.opt/bin:/usr/local/cpanel/3rdparty/perl/514/bin:/usr/local/cpanel/3rdparty/bin:/usr/local/cpanel/3rdparty/node/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
    PERL5LIB=/usr/local/cpanel
    PERLBREW_BASHRC_VERSION=0.73
    PERLBREW_HOME=/root/.perlbrew
    PERLBREW_ROOT=/root/perl5/perlbrew
    PERL_BADLANG (unset)
    SHELL=/bin/bash

@p5pRT
Copy link
Author

p5pRT commented Sep 25, 2015

From @jkeenan

On Thu Sep 24 23​:11​:32 2015, felipe@​felipegasper.com wrote​:

This is a bug report for perl from felipe@​felipegasper.com,
generated with the help of perlbug 1.39 running under perl 5.14.4.

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

The docs for %! in perlvar don’t discuss the actual values of %!.
I noticed recently that th values of this hash match up with the
corresponding Errno values; e.g.​:

{
local $! = 5; #EIO on Linux
print $!{'EIO'}; #prints 5, or Errno​::EIO().
}

The docs seem to indicate that the values of this hash, though,
are simply “truthy” or “falsey”; i.e., not to rely on them for
anything more interesting.

Is this still the case? Or, may language users depend on values of
%! to match up with the corresponding Errno.pm constants?

Some clarification in the docs would be welcome. Thank you!

Here is what I believe is the most relevant documentation of %! as found in blead.

#####
pod/perlvar.pod (line 1812)

=item %OS_ERROR

=item %ERRNO

=item %!
X<%!> X<%OS_ERROR> X<%ERRNO>

Each element of C<%!> has a true value only if C<$!> is set to that
value. For example, C<$!{ENOENT}> is true if and only if the current
value of C<$!> is C<ENOENT>; that is, if the most recent error was "No
such file or directory" (or its moral equivalent​: not all operating
systems give that exact error, and certainly not all languages). To
check if a particular key is meaningful on your system, use C<exists
$!{the_key}>; for a list of legal keys, use C<keys %!>. See L<Errno>
for more information, and also see L</$!>.

pod/perldiag.pod (line 1355)

=item Can't use %! because Errno.pm is not available

(F) The first time the C<%!> hash is used, perl automatically loads the
Errno.pm module. The Errno module is expected to tie the %! hash to
provide symbolic names for C<$!> errno values.
#####

Can you suggest specific improvements?

Thank you very much.

--
James E Keenan (jkeenan@​cpan.org)

@p5pRT
Copy link
Author

p5pRT commented Sep 25, 2015

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

@p5pRT
Copy link
Author

p5pRT commented Sep 26, 2015

From @FGasper

On 25 Sep 2015 6​:51 PM, James E Keenan via RT wrote​:

On Thu Sep 24 23​:11​:32 2015, felipe@​felipegasper.com wrote​:

This is a bug report for perl from felipe@​felipegasper.com,
generated with the help of perlbug 1.39 running under perl 5.14.4.

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

The docs for %! in perlvar don’t discuss the actual values of %!.
I noticed recently that th values of this hash match up with the
corresponding Errno values; e.g.​:

{
local $! = 5; #EIO on Linux
print $!{'EIO'}; #prints 5, or Errno​::EIO().
}

The docs seem to indicate that the values of this hash, though,
are simply “truthy” or “falsey”; i.e., not to rely on them for
anything more interesting.

Is this still the case? Or, may language users depend on values of
%! to match up with the corresponding Errno.pm constants?

Some clarification in the docs would be welcome. Thank you!

Here is what I believe is the most relevant documentation of %! as found in blead.

#####
pod/perlvar.pod (line 1812)

=item %OS_ERROR

=item %ERRNO

=item %!
X<%!> X<%OS_ERROR> X<%ERRNO>

Each element of C<%!> has a true value only if C<$!> is set to that
value. For example, C<$!{ENOENT}> is true if and only if the current
value of C<$!> is C<ENOENT>; that is, if the most recent error was "No
such file or directory" (or its moral equivalent​: not all operating
systems give that exact error, and certainly not all languages). To
check if a particular key is meaningful on your system, use C<exists
$!{the_key}>; for a list of legal keys, use C<keys %!>. See L<Errno>
for more information, and also see L</$!>.

Can you suggest specific improvements?

Maybe​:


The keys of %! are the names of constants from the Errno.pm module like
ENOENT and EPERM. The values depend on the value of $!​:

* When $! is 0, every value of %! is 0.

* When $! is not 0, the value of %! whose key corresponds to the Errno
constant that matches $! is set to the value of that Errno constant.
(Every other value is 0.)

For example, if EIO is 5 and $! is set to 5, then $!{'EIO'} will be 5,
and every other %! value will be 0.

This is useful for handling specific I/O errors, like so​:

open my $fh, '<', $path or do {
  if ($!{'ENOENT'}) {
  warn "“$path” does not exist!";
  }
  else {
  die "Failed to open “$path”​: $!";
  }
};


-FG

@p5pRT
Copy link
Author

p5pRT commented Sep 29, 2015

From @ap

* Felipe Gasper <felipe@​felipegasper.com> [2015-09-26 09​:35]​:

This is useful for handling specific I/O errors, like so​:

open my $fh, '<', $path or do {
if ($!{'ENOENT'}) {
warn "“$path” does not exist!";
}
else {
die "Failed to open “$path”​: $!";
}
};

Which only uses the value’s truthiness…

Do you have an example where the correspondence of value to errno code
is specifically important?

@p5pRT
Copy link
Author

p5pRT commented Sep 29, 2015

From @FGasper

On 29 Sep 2015 8​:54 AM, Aristotle Pagaltzis via RT wrote​:

* Felipe Gasper <felipe@​felipegasper.com> [2015-09-26 09​:35]​:

This is useful for handling specific I/O errors, like so​:

open my $fh, '<', $path or do {
if ($!{'ENOENT'}) {
warn "“$path” does not exist!";
}
else {
die "Failed to open “$path”​: $!";
}
};

Which only uses the value’s truthiness…

Do you have an example where the correspondence of value to errno code
is specifically important?

I’ve seen people do this​:

if ( $! == $!{'ENOENT'} ) {
...
}

… in response to which I, as reviewer, said, “but the documentation only
says truthy/falsey”. It then turned out that the code in question does
indeed work, though the docs don’t imply that it would.

Honestly, I was expecting the values to be just q<> or 1, consistent
with other parts of Perl that return truthy/falsey (e.g., print()), but
even back to 5.8 they’re 0 and Errno.

Basically, if the values are more informative/useful than just being q<>
and 1, the docs might as well advertise what other “feature” they possess.

-FG

@p5pRT
Copy link
Author

p5pRT commented Sep 29, 2015

From @ikegami

On Tue, Sep 29, 2015 at 10​:02 AM, Felipe Gasper <felipe@​felipegasper.com>
wrote​:

I’ve seen people do this​:

if ( $! == $!{'ENOENT'} ) {
...
}

I don't think that's something we'd want to encourage. They should have used

if ( $!{ENOENT} )

or

if ( $! == ENOENT )

@p5pRT
Copy link
Author

p5pRT commented Sep 29, 2015

From @FGasper

On 29 Sep 2015 9​:59 AM, Eric Brine via RT wrote​:

On Tue, Sep 29, 2015 at 10​:02 AM, Felipe Gasper <felipe@​felipegasper.com>
wrote​:

I’ve seen people do this​:

if ( $! == $!{'ENOENT'} ) {
...
}

I don't think that's something we'd want to encourage. They should have used

if ( $!{ENOENT} )

or

if ( $! == ENOENT )

I agree, but right now the docs imply something that the reality doesn’t
bear out.

Maybe an example of correct use of %! could be added to the docs?


my @​nonfatal = qw( EACCES EDQUOT );

open( my $fh, '>', $cache_file_path ) or do {
  if ( grep { $!{$_} } @​nonfatal ) {
  warn "Non-fatal error in opening cache file​: $!";
  }
  else {
  die "Fatal error in opening cache file​: $!";
  }
};


Still, just in general, for Perl to have nontrivial,
potentially-accidentally-working “features” beyond what it advertises
seems less than ideal. I suppose that could also be resolved by making
%! give the same truthy/falsey values (q() and 1) that print() et al.
give, but that may break existing applications.

-FG

@p5pRT
Copy link
Author

p5pRT commented Sep 29, 2015

From @ikegami

On Tue, Sep 29, 2015 at 1​:02 PM, Felipe Gasper <felipe@​felipegasper.com>
wrote​:

I agree, but right now the docs imply something that the reality doesn’t
bear out.

Hum? What do you think the docs imply that's not true?

@p5pRT
Copy link
Author

p5pRT commented Sep 29, 2015

From @FGasper

On 29 Sep 2015 1​:24 PM, Eric Brine wrote​:

On Tue, Sep 29, 2015 at 1​:02 PM, Felipe Gasper <felipe@​felipegasper.com
<mailto​:felipe@​felipegasper.com>> wrote​:

I agree\, but right now the docs imply something that the reality
doesn’t bear out\.

Hum? What do you think the docs imply that's not true?

IMO the docs imply that the following should not work​:

if ( $! == $!{'ENOENT'} ) { .. }

...given the context of how the rest of Perl implements returns that are
documented as merely truthy or falsey.

Given that we don’t want people to write the above, why *does* Perl
allow it to work by making the truthy %! values anything besides 1?

-FG

@p5pRT
Copy link
Author

p5pRT commented Sep 29, 2015

From @ikegami

On Tue, Sep 29, 2015 at 2​:41 PM, Felipe Gasper <felipe@​felipegasper.com>
wrote​:

On 29 Sep 2015 1​:24 PM, Eric Brine wrote​:

On Tue, Sep 29, 2015 at 1​:02 PM, Felipe Gasper <felipe@​felipegasper.com
<mailto​:felipe@​felipegasper.com>> wrote​:

I agree\, but right now the docs imply something that the reality
doesn’t bear out\.

Hum? What do you think the docs imply that's not true?

IMO the docs imply that the following should not work​:

if ( $! == $!{'ENOENT'} ) { .. }

Right, so the **code** should be changed

@p5pRT
Copy link
Author

p5pRT commented Sep 29, 2015

From @ikegami

On Tue, Sep 29, 2015 at 2​:41 PM, Felipe Gasper <felipe@​felipegasper.com>
wrote​:

On 29 Sep 2015 1​:24 PM, Eric Brine wrote​:

On Tue, Sep 29, 2015 at 1​:02 PM, Felipe Gasper <felipe@​felipegasper.com
<mailto​:felipe@​felipegasper.com>> wrote​:

I agree\, but right now the docs imply something that the reality
doesn’t bear out\.

Hum? What do you think the docs imply that's not true?

IMO the docs imply that the following should not work​:

if ( $! == $!{'ENOENT'} ) { .. }

The docs only imply that the above is wrong. I'm with the docs on this one.
As Aristotle asked, do you have an example where the correspondence of
value to errno code is specifically important?

@p5pRT
Copy link
Author

p5pRT commented Sep 29, 2015

From @FGasper

On 29 Sep 2015 3​:08 PM, Eric Brine wrote​:

On Tue, Sep 29, 2015 at 2​:41 PM, Felipe Gasper <felipe@​felipegasper.com
<mailto​:felipe@​felipegasper.com>> wrote​:

On 29 Sep 2015 1&#8203;:24 PM\, Eric Brine wrote&#8203;:

    On Tue\, Sep 29\, 2015 at 1&#8203;:02 PM\, Felipe Gasper
    \<felipe@&#8203;felipegasper\.com \<mailto&#8203;:felipe@&#8203;felipegasper\.com>
    \<mailto&#8203;:felipe@&#8203;felipegasper\.com
    \<mailto&#8203;:felipe@&#8203;felipegasper\.com>>> wrote&#8203;:

         I agree\, but right now the docs imply something that the
    reality
         doesn’t bear out\.


    Hum? What do you think the docs imply that's not true?


IMO the docs imply that the following should not work&#8203;:

if \( $\! == $\!\{'ENOENT'\} \) \{ \.\. \}

The docs only imply that the above is wrong. I'm with the docs on this
one. As Aristotle asked, do you have an example where the correspondence
of value to errno code is specifically important?

I don’t have an example of *good* code where the correspondence is
important, no. Seeing a colleague write the above, and being surprised
that it actually did what was intended, was what inspired the present
thread.

This has been this way at least since Perl 5.8, and possibly longer.
Changing the code now would unnecessarily risk breaking
something--admittedly, something badly written, but ISTM more sensible
pragmatically to update the docs to describe the correspondence.

It could be as simple as​: “A nonzero value of %! will match the key’s
corresponding errno value.”

If nothing else, is there general agreement that adding a (good) usage
example would improve this documentation?

-FG

@p5pRT
Copy link
Author

p5pRT commented Sep 29, 2015

From @ap

* Felipe Gasper <felipe@​felipegasper.com> [2015-09-29 22​:20]​:

I don’t have an example of *good* code where the correspondence is
important, no.

Me neither, that’s why I asked. I can’t come up with a use for it.

Seeing a colleague write the above, and being surprised that it
actually did what was intended, was what inspired the present thread.

This has been this way at least since Perl 5.8, and possibly longer.
Changing the code now would unnecessarily risk breaking
something

Yes, and there doesn’t seem to be any positive value to be had from the
pain imposed on users.

admittedly, something badly written, but ISTM more sensible
pragmatically to update the docs to describe the correspondence.

It could be as simple as​: “A nonzero value of %! will match the key’s
corresponding errno value.”

That’s what I don’t get, though. If it’s documented, more people will
write code like that, intentionally. It becomes somewhat of a self-
fulfilling promise that the interface isn’t going to change. Is there
harm in leaving the exact value unspecified?

If nothing else, is there general agreement that adding a (good) usage
example would improve this documentation?

Dunno, but personally I agree. I can easily imagine that the idea of %!
not just mapping errno names to codes but actually reflecting the state
of $! would not be intuitively catchy for some people, leading to code
of the kind your colleague wrote. An example would take care of that.

Regards,
--
Aristotle Pagaltzis // <http​://plasmasturm.org/>

@p5pRT
Copy link
Author

p5pRT commented Sep 29, 2015

From @Abigail

On Wed, Sep 30, 2015 at 01​:18​:36AM +0200, Aristotle Pagaltzis wrote​:

* Felipe Gasper <felipe@​felipegasper.com> [2015-09-29 22​:20]​:

I don’t have an example of *good* code where the correspondence is
important, no.

Me neither, that’s why I asked. I can’t come up with a use for it.

Seeing a colleague write the above, and being surprised that it
actually did what was intended, was what inspired the present thread.

This has been this way at least since Perl 5.8, and possibly longer.
Changing the code now would unnecessarily risk breaking
something

Yes, and there doesn’t seem to be any positive value to be had from the
pain imposed on users.

admittedly, something badly written, but ISTM more sensible
pragmatically to update the docs to describe the correspondence.

It could be as simple as​: “A nonzero value of %! will match the key’s
corresponding errno value.”

That’s what I don’t get, though. If it’s documented, more people will
write code like that, intentionally. It becomes somewhat of a self-
fulfilling promise that the interface isn’t going to change. Is there
harm in leaving the exact value unspecified?

You can document what it currently does, and then continue pointing
out that this may change without notice; stating that if they write
code that depends on the current value, their code may break when
they upgrade perl.

It's then up to the programmer what to do with this information --
just because it won't be "upgrade proof" doesn't mean it isn't
suitable for a one-off script.

Abigail

@p5pRT
Copy link
Author

p5pRT commented Sep 30, 2015

From @ysth

On Sep 29, 2015 1​:08 PM, "Eric Brine" <ikegami@​adaelis.com> wrote​:

On Tue, Sep 29, 2015 at 2​:41 PM, Felipe Gasper <felipe@​felipegasper.com>
wrote​:

On 29 Sep 2015 1​:24 PM, Eric Brine wrote​:

On Tue, Sep 29, 2015 at 1​:02 PM, Felipe Gasper <felipe@​felipegasper.com
<mailto​:felipe@​felipegasper.com>> wrote​:

I agree\, but right now the docs imply something that the reality
doesn’t bear out\.

Hum? What do you think the docs imply that's not true?

IMO the docs imply that the following should not work​:

if ( $! == $!{'ENOENT'} ) { .. }

The docs only imply that the above is wrong. I'm with the docs on this
one. As Aristotle asked, do you have an example where the correspondence of
value to errno code is specifically important?

Playing Devil's advocate​:

$expected_err = $!{ENOENT} || $!{EISDIR} || ...
if ($expected_err) {
  handle_expected_err($expected_err);
}
else {
  die "horribly​: $!";
}

@p5pRT
Copy link
Author

p5pRT commented Sep 30, 2015

From @FGasper

On 30 Sep 2015 12​:04 AM, Yitzchak Scott-Thoennes wrote​:

On Sep 29, 2015 1​:08 PM, "Eric Brine" <ikegami@​adaelis.com
<mailto​:ikegami@​adaelis.com>> wrote​:

On Tue, Sep 29, 2015 at 2​:41 PM, Felipe Gasper
<felipe@​felipegasper.com <mailto​:felipe@​felipegasper.com>> wrote​:

On 29 Sep 2015 1​:24 PM, Eric Brine wrote​:

On Tue, Sep 29, 2015 at 1​:02 PM, Felipe Gasper
<felipe@​felipegasper.com <mailto​:felipe@​felipegasper.com>
<mailto​:felipe@​felipegasper.com <mailto​:felipe@​felipegasper.com>>>
wrote​:

I agree\, but right now the docs imply something that the reality
doesn’t bear out\.

Hum? What do you think the docs imply that's not true?

IMO the docs imply that the following should not work​:

if ( $! == $!{'ENOENT'} ) { .. }

The docs only imply that the above is wrong. I'm with the docs on
this one. As Aristotle asked, do you have an example where the
correspondence of value to errno code is specifically important?

Playing Devil's advocate​:

$expected_err = $!{ENOENT} || $!{EISDIR} || ...
if ($expected_err) {
handle_expected_err($expected_err);
}
else {
die "horribly​: $!";
}

Devil’s advocate again​:

if ($!{ENOENT} || $!{EISDIR} || ..) {
  handle_expected_err($!);
}
...

-FG

@p5pRT
Copy link
Author

p5pRT commented Sep 30, 2015

From @ysth

On Sep 29, 2015 10​:08 PM, "Felipe Gasper" <felipe@​felipegasper.com> wrote​:

Devil’s advocate again​:

if ($!{ENOENT} || $!{EISDIR} || ..) {
handle_expected_err($!);
}
...

Passing errorish globals is usually not a good idea; the caller may
inadvertently modify it before copying the passed value.

@p5pRT
Copy link
Author

p5pRT commented Sep 30, 2015

From @ysth

On Sep 29, 2015 10​:15 PM, "Yitzchak Scott-Thoennes" <sthoenna@​gmail.com>
wrote​:

On Sep 29, 2015 10​:08 PM, "Felipe Gasper" <felipe@​felipegasper.com> wrote​:

Devil’s advocate again​:

if ($!{ENOENT} || $!{EISDIR} || ..) {
handle_expected_err($!);
}
...

Passing errorish globals is usually not a good idea; the caller may
inadvertently modify it before copying the passed value.

I mean callee

@p5pRT
Copy link
Author

p5pRT commented Sep 30, 2015

From @FGasper

On 30 Sep 2015 12​:15 AM, Yitzchak Scott-Thoennes wrote​:

On Sep 29, 2015 10​:08 PM, "Felipe Gasper" <felipe@​felipegasper.com
<mailto​:felipe@​felipegasper.com>> wrote​:

Devil’s advocate again​:

if ($!{ENOENT} || $!{EISDIR} || ..) {
handle_expected_err($!);
}
...

Passing errorish globals is usually not a good idea; the callee may
inadvertently modify it before copying the passed value.

if ($!{ENOENT} || $!{EISDIR} || ..) {
  handle_expected_err(my $err = $!);
}

;-)

@p5pRT
Copy link
Author

p5pRT commented Sep 30, 2015

From @rjbs

I have pushed 3b90fd9, which documents what value people may have expected in the past, and says to expect nothing beyond truth, for safety's sake.

Ticket resolved.

--
rjbs

@p5pRT p5pRT closed this as completed Sep 30, 2015
@p5pRT
Copy link
Author

p5pRT commented Sep 30, 2015

@rjbs - Status changed from 'open' to 'resolved'

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

No branches or pull requests

1 participant