undocumented (A) alien encoding warnings

[Tom Christiansen]

This:

binmode(STDIN, ":BogusNoneSuch")

quietly fails and sets errno to ENOENT; that's fine.

But this:

binmode(STDIN, ":encoding(BogusNoneSuch)")

unquietly fails and sets errno to EINVAL with
ext/PerlIO-encoding/encoding.xs emitting the
unsuppressible warning:

Cannot find encoding "BogusNoneSuch"

While reasonably obvious, this message is not in perldiag(1) at all, let
alone classed as a mandatory unsuppressible warning--in fact, there is no
such class, apart (perhaps) from A for Alien. That means that you cannot
get a longer description of the warning with -Mdiagnostics.

Also, oddly enough considering

./ext/PerlIO-encoding/encoding.xs: Perl_warner(aTHX_ packWARN(WARN_IO), "Cannot find encoding \"%" SVf "\"",

you cannot suppress it with -X, and you cannot control it with no warnings 'io'.

% perl -X -le 'binmode(STDIN, ":encoding(txt)") || die $!'
Cannot find encoding "txt" at -e line 1.
Invalid argument at -e line 1.
Exit 22

% perl -le 'use warnings; no warnings "io"; binmode(STDIN, ":encoding(txt)") || die $!'
Cannot find encoding "txt" at -e line 1.
Invalid argument at -e line 1.
Exit 22

Apart from diddling STDERR or $SIG{__WARN__}, might I inquire what the user
is expected to do with this? I found no mention in any documentation about
it, but I did not look for such completely exhaustively, either; it wasn't
in any of the obvious places.

Both of ext/PerlIO-encoding/t/{encoding,nolooping}.t diddle $SIG{__WARN__}
to cope, but this strikes me as extreme. We're revealing something about
the implementation and forcing users to deal with any warnings in an
abnormal way: Is this truly both correct and desirable behavior?

I'm also suspecting these errnos are more accidental than intentional.

chthon% perl -le 'use warnings; no warnings "io"; binmode(STDIN, ":Encoding(txt)") || die $!'
No such file or directory at -e line 1.
Exit 2

I understand why, but such different behavior from a tiny casing
discrepancy seems disproportionately untiny; perhaps I just have
disproportionate expectations of foolish consistencies.

--tom

[Tom Christiansen]

More succinctly:

1. Is it a bug that :encoding(Wrong) errors trigger warnings not subject to
"no warnings", and which can only be intercepted with $SIG{__WARN__}?

2. Is it a bug that specifying a :Wrong I/O layer sets errno to ENOENT
while :encoding(Wrong) sets EINVAL? Shouldn't both cause EINVAL?

--tom

[Rafael Garcia-Suarez]

tchrist@ :

> More succinctly:
>
> 1. Is it a bug that :encoding(Wrong) errors trigger warnings not subject to
>   "no warnings", and which can only be intercepted with $SIG{__WARN__}?

Indeed it is. Fixed by
http://perl5.git.perl.org/perl.git/commitdiff/1bb5f2059539b5573bb73de8c3a235284687220b

I made them mandatory warnings, so they're still on by default. I'll
add them in perldiag too.

[Tom Christiansen]

Rafa�l wrote:

>> More succinctly:
>>
>> 1. Is it a bug that :encoding(Wrong) errors trigger warnings not subject to

>> # "no warnings", and which can only be intercepted with $SIG{__WARN__}?

> Indeed it is. Fixed by
> http://perl5.git.perl.org/perl.git/commitdiff/1bb5f2059539b5573bb73de8c3a235284687220b

> I made them mandatory warnings, so they're still on by default. I'll
> add them in perldiag too.

Oh, good. Thanks very much.

--tom