Re: RFC 140 (v1) One Should Not Get Away With Ignoring System Call Errors
"JH" == Jarkko Hietaniemi [EMAIL PROTECTED] writes:
JH "The first operation done on the return value of open() shall be defined()
JH or you shall regret your pitiful existence."? (a flag on the scalar coming
JH from open that makes any other op than defined() to die and defined() clears
JH the flag)
Ala, taint? Except the variable is tainted with death?
Hmm, this would make two types of undef. Actually, if a callee could
death-taint a variable then the return death_tainted(42) would make
the caller check his values on first use.
But the drawback would be that the actual victim may not be the primal
cause.
sub foo {
my $fh = open();
... Lots more code ...
return $fh;
}
$victim = foo;
print $victim "I'm helpless";
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 140 (v1) One Should Not Get Away With Ignoring System Call Errors
On Thu, Aug 24, 2000 at 02:09:15PM -0400, Chaim Frenkel wrote:
"JH" == Jarkko Hietaniemi [EMAIL PROTECTED] writes:
JH "The first operation done on the return value of open() shall be defined()
JH or you shall regret your pitiful existence."? (a flag on the scalar coming
JH from open that makes any other op than defined() to die and defined() clears
JH the flag)
Ala, taint? Except the variable is tainted with death?
Yes, sort of. "Touch me and I'll bring you down."
Hmm, this would make two types of undef. Actually, if a callee could
(Not really undef, boolean, see Tom's reply). But in either case not
a problem since the user should have no explicit means of telling the
kinds part nor certainly ways of changing the kind.
But the drawback would be that the actual victim may not be the primal
cause.
sub foo {
my $fh = open();
... Lots more code ...
return $fh;
}
$victim = foo;
print $victim "I'm helpless";
Tough.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
Re: RFC 140 (v1) One Should Not Get Away With Ignoring System Call Errors
"JH" == Jarkko Hietaniemi [EMAIL PROTECTED] writes:
But the drawback would be that the actual victim may not be the primal
cause.
sub foo {
my $fh = open();
... Lots more code ...
return $fh;
}
$victim = foo;
print $victim "I'm helpless";
JH Tough.
Not a nice attitude. The failure is not close to the cause. Neither in
time or space.
If it were closer to the open, at least an intellegent message might
be displayed. Your way, nothing but.
*ARRGGHHH*, tainted data, in Foo.pl at line 37 chunk 12
(Why does that remind me of rogue?)
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 140 (v1) One Should Not Get Away With Ignoring System Call Errors
I believe Dan said that he wanted to make objects a lot faster in P6. I don't think we should be precluded from requesting Things That Make Sense (tm) just because the current implementation is sub-optimal in performance if nothing inherently prevents a better implementation. I don't think we should assume that we can't scratch our nose without getting overly object-happy. For the particular aspect I'm driving at there is no *need* for objects of any kind, no catch, no throw, no structured exceptions: I want the program simply to _die_. I'm not against someone else providing higher level ways handle/trap/propagate those croakings, be the way procedural or OO or what is the rave du jour. Don't get me wrong: for some purposes and somtimes I like structured warnings. But what I am proposing is very low-level, it's below the level of Perl the language, actually. Think of it as a cleaned-up consistent wrapping of the current C library APIs. If somebody wants to further wrap these failures into something nicer, okay, I have no problem with that. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
