Re: [perl #60732] Hash indexes shouldn't work on array refs
jerry gay wrote: On Fri, Nov 21, 2008 at 10:43, via RT Moritz Lenz [EMAIL PROTECTED] wrote: # New Ticket Created by Moritz Lenz # Please include the string: [perl #60732] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60732 From #perl6 today: 19:33 moritz_ rakudo: my $x = [ 42 ]; say $x0 19:33 p6eval rakudo 32984: OUTPUT[42] I don't think that should be allowed. the real test is: (8:52:47 PM) [particle]1: rakudo: my $x = [42]; say $x0_but_true; (8:52:49 PM) p6eval: rakudo 32998: OUTPUT[42] (8:53:38 PM) [particle]1: rakudo: my $x = [42]; say $xtrue_but_0; (8:53:40 PM) p6eval: rakudo 32998: OUTPUT[42] (8:53:50 PM) [particle]1: rakudo: my $x = [42]; say $xXXX; (8:53:52 PM) p6eval: rakudo 32998: OUTPUT[42] (8:54:37 PM) [particle]1: rakudo: my $x = ['a', 42]; say $xXXX; (8:54:39 PM) p6eval: rakudo 32998: OUTPUT[a] (8:58:41 PM) [particle]1: rakudo: my $x = ['a', 42]; say $x1.4; (8:58:44 PM) p6eval: rakudo 32998: OUTPUT[42] (8:58:48 PM) [particle]1: rakudo: my $x = ['a', 42]; say $x0.4; (8:58:50 PM) p6eval: rakudo 32998: OUTPUT[a] so, the index is coerced to an integer. is that really wrong? ~jerry IMHO yes, because Perl explicitly distinguishes between arrays and hashes (and it's one of the things we never regretted, I think ;-). Any intermixing between the two would only lead to confusion, especially if somebody writes a class whose objects are both hashe and array. But that's just my two cents, CC'ing p6l for clarification. Moritz
Re: S16: chown, chmod
On Nov 23, 4:55 pm, [EMAIL PROTECTED] (Aristotle Pagaltzis) wrote:
I don’t see any examples in S16 concerning error handling anyway,
but even so I don’t see how relying on exceptions would could
possibly be more complex than guard clauses.
Neither do I. Catching Failure objects is better than explicit checks
(except where performance implications exist and are relevant to the
application -- which isn't the case here).
Dave.
PS. From S16, q{ ... On POSIX systems, you can detect this condition
this way:
use POSIX qw(sysconf _PC_CHOWN_RESTRICTED);
$can_chown_giveaway = not sysconf(_PC_CHOWN_RESTRICTED);
}
From this I inferred that the purpose of this assignment was to do a
check -- I apologize if I misinterpreted it -- and would suggest that
we should either get rid of that text, or else reword to suggest not
using it in bad ways.
Re: [perl #60732] Hash indexes shouldn't work on array refs
Moritz Lenz wrote in perl.perl6.compiler : jerry gay wrote: On Fri, Nov 21, 2008 at 10:43, via RT Moritz Lenz [EMAIL PROTECTED] wrote: # New Ticket Created by Moritz Lenz # Please include the string: [perl #60732] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60732 From #perl6 today: 19:33 moritz_ rakudo: my $x = [ 42 ]; say $x0 19:33 p6eval rakudo 32984: OUTPUT[42] I don't think that should be allowed. the real test is: (8:52:47 PM) [particle]1: rakudo: my $x = [42]; say $x0_but_true; (8:52:49 PM) p6eval: rakudo 32998: OUTPUT[42] (8:53:38 PM) [particle]1: rakudo: my $x = [42]; say $xtrue_but_0; (8:53:40 PM) p6eval: rakudo 32998: OUTPUT[42] (8:53:50 PM) [particle]1: rakudo: my $x = [42]; say $xXXX; (8:53:52 PM) p6eval: rakudo 32998: OUTPUT[42] (8:54:37 PM) [particle]1: rakudo: my $x = ['a', 42]; say $xXXX; (8:54:39 PM) p6eval: rakudo 32998: OUTPUT[a] (8:58:41 PM) [particle]1: rakudo: my $x = ['a', 42]; say $x1.4; (8:58:44 PM) p6eval: rakudo 32998: OUTPUT[42] (8:58:48 PM) [particle]1: rakudo: my $x = ['a', 42]; say $x0.4; (8:58:50 PM) p6eval: rakudo 32998: OUTPUT[a] so, the index is coerced to an integer. is that really wrong? ~jerry IMHO yes, because Perl explicitly distinguishes between arrays and hashes (and it's one of the things we never regretted, I think ;-). Any intermixing between the two would only lead to confusion, especially if somebody writes a class whose objects are both hashe and array. Yes, that leads to confusion. (And confusion leads to anger, and so on) Which is why we removed pseudo-hashes from Perl 5.10. -- The key words SHALT, SHALT NOT, SMITE, and PILLAR OF SALT in this document are to be interpreted as expected. -- RFC 4041
Re: [perl #60732] Hash indexes shouldn't work on array refs
On Mon, Nov 24, 2008 at 7:19 AM, Rafael Garcia-Suarez [EMAIL PROTECTED] wrote: Moritz Lenz wrote in perl.perl6.compiler : jerry gay wrote: On Fri, Nov 21, 2008 at 10:43, via RT Moritz Lenz [EMAIL PROTECTED] wrote: # New Ticket Created by Moritz Lenz # Please include the string: [perl #60732] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60732 From #perl6 today: 19:33 moritz_ rakudo: my $x = [ 42 ]; say $x0 19:33 p6eval rakudo 32984: OUTPUT[42] I don't think that should be allowed. the real test is: (8:52:47 PM) [particle]1: rakudo: my $x = [42]; say $x0_but_true; (8:52:49 PM) p6eval: rakudo 32998: OUTPUT[42] (8:53:38 PM) [particle]1: rakudo: my $x = [42]; say $xtrue_but_0; (8:53:40 PM) p6eval: rakudo 32998: OUTPUT[42] (8:53:50 PM) [particle]1: rakudo: my $x = [42]; say $xXXX; (8:53:52 PM) p6eval: rakudo 32998: OUTPUT[42] (8:54:37 PM) [particle]1: rakudo: my $x = ['a', 42]; say $xXXX; (8:54:39 PM) p6eval: rakudo 32998: OUTPUT[a] (8:58:41 PM) [particle]1: rakudo: my $x = ['a', 42]; say $x1.4; (8:58:44 PM) p6eval: rakudo 32998: OUTPUT[42] (8:58:48 PM) [particle]1: rakudo: my $x = ['a', 42]; say $x0.4; (8:58:50 PM) p6eval: rakudo 32998: OUTPUT[a] so, the index is coerced to an integer. is that really wrong? ~jerry IMHO yes, because Perl explicitly distinguishes between arrays and hashes (and it's one of the things we never regretted, I think ;-). Any intermixing between the two would only lead to confusion, especially if somebody writes a class whose objects are both hashe and array. Yes, that leads to confusion. (And confusion leads to anger, and so on) Which is why we removed pseudo-hashes from Perl 5.10. Perl 6 explicitly _does_ allow hash-reference syntax, for the specific purpose of customized indices. That said, the sample code would not work, since you must explicitly define your custom index before you use it. Examples from the Synopses include a custom index that's based on the months of the year, so that you can say, e.g., @xJan instead of @x[0]. -- Jonathan Dataweaver Lang
Re: S16: chown, chmod
On 2008 Nov 24, at 10:36, dpuu wrote: On Nov 23, 3:56 pm, [EMAIL PROTECTED] (Brandon S. Allbery KF8NH) wrote: I think you're seeing something other than what we are. Checking any external resource before operating on it introduces a race condition which can allow an attacker to swap resources on you, so the item you (in this case) chown() isn't the one you tested. If the chown is restricted then it's going to fail anyway, assuming that the underlying Unix function fails. If chown can succeed incorrectly then there's nothing that P6 can do to prevent that. My Still misunderstanding, I think. Yes, it will fail anyway, but in the general case you're checking to see if as a privileged process it is safe to operate on a given file. In such case the correct thing to do is relinquish privilege and then simply do the operation, trapping any error --- not testing and then doing it. (I grant this isn't quite the same thing --- unless you're trying to decide if your root process should chown() a file on behalf of an unprivileged process.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH
Re: S16: chown, chmod
On 2008 Nov 24, at 10:45, dpuu wrote:
PS. From S16, q{ ... On POSIX systems, you can detect this condition
this way:
use POSIX qw(sysconf _PC_CHOWN_RESTRICTED);
$can_chown_giveaway = not sysconf(_PC_CHOWN_RESTRICTED);
}
From this I inferred that the purpose of this assignment was to do a
check -- I apologize if I misinterpreted it -- and would suggest that
we should either get rid of that text, or else reword to suggest not
using it in bad ways.
The latter, I think; it can be useful to know whether the system
permits or not (although you also need to use pathconf() to check if
the filesystem in question allows it or not), but using it as a
*security* check is a bad idea. OTOH Perl has historically not said
much about doing that kind of thing.
--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon universityKF8NH
