[33130] in Perl-Users-Digest
Perl-Users Digest, Issue: 4407 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Apr 4 09:09:20 2015
Date: Sat, 4 Apr 2015 06:09:06 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sat, 4 Apr 2015 Volume: 11 Number: 4407
Today's topics:
Re: Backticks status in scalar context: bug or missunde <peter@makholm.net>
Re: Backticks status in scalar context: bug or missunde <ams@luminous.ludd.ltu.se>
Re: Backticks status in scalar context: bug or missunde <gamo@telecable.es>
Re: Backticks status in scalar context: bug or missunde <greg.at.softsprocket@dot.com>
Re: Backticks status in scalar context: bug or missunde <gamo@telecable.es>
Re: Backticks status in scalar context: bug or missunde <rweikusat@mobileactivedefense.com>
Re: Backticks status in scalar context: bug or missunde <gamo@telecable.es>
Re: Backticks status in scalar context: bug or missunde <rweikusat@mobileactivedefense.com>
Re: Backticks status in scalar context: bug or missunde <news@todbe.com>
Re: Backticks status in scalar context: bug or missunde <dmcanzi@uwaterloo.ca>
Re: Backticks status in scalar context: bug or missunde <rweikusat@mobileactivedefense.com>
Does "exit" closes all filehandles? <gamo@telecable.es>
Re: Does "exit" closes all filehandles? <news@todbe.com>
Re: Error Messages <edgrsprj@ix.netcom.com>
Re: One more reason I like Perl. <bauhaus@futureapps.invalid>
Re: One more reason I like Perl. <rweikusat@mobileactivedefense.com>
Re: One more reason I like Perl. (Seymour J.)
Re: One more reason I like Perl. <bauhaus@futureapps.invalid>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 02 Apr 2015 15:24:42 +0200
From: Peter Makholm <peter@makholm.net>
Subject: Re: Backticks status in scalar context: bug or missunderstanding
Message-Id: <87619e7jdx.fsf@vps1.hacking.dk>
Martin Str|mberg <ams@luminous.ludd.ltu.se> writes:
> Let me point out the part that is relevant:
>
> In scalar context, it comes back as a single string, or undef if the command
> failed.
The issue is the exact definition of 'failed'. I think that a more
complete description wpuld be 'or undef if the command failed to
execute'.
In your case the command did ran correctly, but it returned no output
and a status code of 1. If you want the status code you need to look at
the variable $? (specifically $? >>8, see 'perlvar -v '$?').
A filure would be if the command didn't exist, wasn't executable, or
that the execve system call failed for some other reason.
//Makholm
------------------------------
Date: Thu, 2 Apr 2015 13:55:24 +0000 (UTC)
From: Martin Str|mberg <ams@luminous.ludd.ltu.se>
Subject: Re: Backticks status in scalar context: bug or missunderstanding
Message-Id: <mfjhoa$5to$1@speranza.aioe.org>
Peter Makholm <peter@makholm.net> wrote:
> Martin Str|mberg <ams@luminous.ludd.ltu.se> writes:
> > Let me point out the part that is relevant:
> >
> > In scalar context, it comes back as a single string, or undef if the command
> > failed.
> The issue is the exact definition of 'failed'. I think that a more
> complete description wpuld be 'or undef if the command failed to
> execute'.
> In your case the command did ran correctly, but it returned no output
> and a status code of 1. If you want the status code you need to look at
> the variable $? (specifically $? >>8, see 'perlvar -v '$?').
> A filure would be if the command didn't exist, wasn't executable, or
> that the execve system call failed for some other reason.
Ok, that explains what is happening. If I try the command
"/bin/false_does_not_exists", I do get undef.
Thanks.
However, IMO, that part of the documentation is severly misleading. I'll
quote part of it again:
The collected standard output of the command is returned. ... In scalar
context, it comes back as a single string, or undef if the command failed.
First it says uses "command" in the sense program executed, then the second
"command" isn't the same command as the first but the act of forking and
execing.
I dare say, anyone reading this will assume the "undef if the command failed"
will assume what I did and that `/bin/false` will return undef.
--
MartinS
------------------------------
Date: Thu, 02 Apr 2015 16:28:26 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Backticks status in scalar context: bug or missunderstanding
Message-Id: <mfjjmk$atg$1@speranza.aioe.org>
El 02/04/15 a las 15:24, Peter Makholm escribió:
> Martin Str|mberg <ams@luminous.ludd.ltu.se> writes:
>
>> Let me point out the part that is relevant:
>>
>> In scalar context, it comes back as a single string, or undef if the command
>> failed.
>
> The issue is the exact definition of 'failed'. I think that a more
> complete description wpuld be 'or undef if the command failed to
> execute'.
>
> In your case the command did ran correctly, but it returned no output
> and a status code of 1. If you want the status code you need to look at
> the variable $? (specifically $? >>8, see 'perlvar -v '$?').
>
> A filure would be if the command didn't exist, wasn't executable, or
> that the execve system call failed for some other reason.
>
> //Makholm
>
Ok, but how does bash knows that /bin/false is false?
TIA
--
http://www.telecable.es/personales/gamo/
The generation of random numbers is too important to be left to chance
------------------------------
Date: Thu, 02 Apr 2015 15:20:56 GMT
From: Greg Martin <greg.at.softsprocket@dot.com>
Subject: Re: Backticks status in scalar context: bug or missunderstanding
Message-Id: <s7dTw.125743$LZ1.58379@fx25.iad>
On 2015-04-02, gamo <gamo@telecable.es> wrote:
> El 02/04/15 a las 15:24, Peter Makholm escribió:
>> Martin Str|mberg <ams@luminous.ludd.ltu.se> writes:
>>
>>> Let me point out the part that is relevant:
>>>
>>> In scalar context, it comes back as a single string, or undef if the command
>>> failed.
>>
>> The issue is the exact definition of 'failed'. I think that a more
>> complete description wpuld be 'or undef if the command failed to
>> execute'.
>>
>> In your case the command did ran correctly, but it returned no output
>> and a status code of 1. If you want the status code you need to look at
>> the variable $? (specifically $? >>8, see 'perlvar -v '$?').
>>
>> A filure would be if the command didn't exist, wasn't executable, or
>> that the execve system call failed for some other reason.
>>
>> //Makholm
>>
>
>
> Ok, but how does bash knows that /bin/false is false?
>
> TIA
>
$ if (false);then echo 'true'; else echo 'false'; fi
false
$ false
$ echo $?
1
It doesn't know it is false - it only knows that a non-zero value was
returned by an executable.
--
http://www.softsprocket.com
------------------------------
Date: Thu, 02 Apr 2015 18:45:58 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Backticks status in scalar context: bug or missunderstanding
Message-Id: <mfjrog$vf3$1@speranza.aioe.org>
El 02/04/15 a las 17:20, Greg Martin escribió:
> On 2015-04-02, gamo <gamo@telecable.es> wrote:
>> El 02/04/15 a las 15:24, Peter Makholm escribió:
>>> Martin Str|mberg <ams@luminous.ludd.ltu.se> writes:
>>>
>>>> Let me point out the part that is relevant:
>>>>
>>>> In scalar context, it comes back as a single string, or undef if the command
>>>> failed.
>>>
>>> The issue is the exact definition of 'failed'. I think that a more
>>> complete description wpuld be 'or undef if the command failed to
>>> execute'.
>>>
>>> In your case the command did ran correctly, but it returned no output
>>> and a status code of 1. If you want the status code you need to look at
>>> the variable $? (specifically $? >>8, see 'perlvar -v '$?').
>>>
>>> A filure would be if the command didn't exist, wasn't executable, or
>>> that the execve system call failed for some other reason.
>>>
>>> //Makholm
>>>
>>
>>
>> Ok, but how does bash knows that /bin/false is false?
>>
>> TIA
>>
>
> $ if (false);then echo 'true'; else echo 'false'; fi
> false
> $ false
> $ echo $?
> 1
>
> It doesn't know it is false - it only knows that a non-zero value was
> returned by an executable.
>
Ok, so what the OP needs is a simple
$r = system($cmd);
if (not $r){
print "true\n";
}else{
print "false\n";
}
Thanks
--
http://www.telecable.es/personales/gamo/
The generation of random numbers is too important to be left to chance
------------------------------
Date: Thu, 02 Apr 2015 17:59:57 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Backticks status in scalar context: bug or missunderstanding
Message-Id: <87twwycvoy.fsf@doppelsaurus.mobileactivedefense.com>
gamo <gamo@telecable.es> writes:
> El 02/04/15 a las 17:20, Greg Martin escribió:
>> On 2015-04-02, gamo <gamo@telecable.es> wrote:
>>> El 02/04/15 a las 15:24, Peter Makholm escribió:
>>>> Martin Str|mberg <ams@luminous.ludd.ltu.se> writes:
>>>>
>>>>> Let me point out the part that is relevant:
>>>>>
>>>>> In scalar context, it comes back as a single string, or undef if the command
>>>>> failed.
>>>>
>>>> The issue is the exact definition of 'failed'. I think that a more
>>>> complete description wpuld be 'or undef if the command failed to
>>>> execute'.
>>>>
>>>> In your case the command did ran correctly, but it returned no output
>>>> and a status code of 1. If you want the status code you need to look at
>>>> the variable $? (specifically $? >>8, see 'perlvar -v '$?').
>>>>
>>>> A filure would be if the command didn't exist, wasn't executable, or
>>>> that the execve system call failed for some other reason.
>>>>
>>>> //Makholm
>>>>
>>>
>>>
>>> Ok, but how does bash knows that /bin/false is false?
>>>
>>> TIA
>>>
>>
>> $ if (false);then echo 'true'; else echo 'false'; fi
>> false
>> $ false
>> $ echo $?
>> 1
>>
>> It doesn't know it is false - it only knows that a non-zero value was
>> returned by an executable.
>>
>
> Ok, so what the OP needs is a simple
>
> $r = system($cmd);
> if (not $r){
> print "true\n";
> }else{
> print "false\n";
> }
system is documented as returning -1 in case of an error on the way to
executing $cmd.
------------------------------
Date: Thu, 02 Apr 2015 23:55:03 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Backticks status in scalar context: bug or missunderstanding
Message-Id: <mfkds0$eoj$1@speranza.aioe.org>
El 02/04/15 a las 18:59, Rainer Weikusat escribió:
> gamo <gamo@telecable.es> writes:
>> Ok, so what the OP needs is a simple
>>
>> $r = system($cmd);
>> if (not $r){
>> print "true\n";
>> }else{
>> print "false\n";
>> }
>
> system is documented as returning -1 in case of an error on the way to
> executing $cmd.
>
Yes, but that works for me and returns true for $cmd = "/bin/true"; and
false with $cmd = "/bin/false"
--
http://www.telecable.es/personales/gamo/
The generation of random numbers is too important to be left to chance
------------------------------
Date: Thu, 02 Apr 2015 23:04:16 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Backticks status in scalar context: bug or missunderstanding
Message-Id: <87ego2chlr.fsf@doppelsaurus.mobileactivedefense.com>
gamo <gamo@telecable.es> writes:
> El 02/04/15 a las 18:59, Rainer Weikusat escribió:
>> gamo <gamo@telecable.es> writes:
>>> Ok, so what the OP needs is a simple
>>>
>>> $r = system($cmd);
>>> if (not $r){
>>> print "true\n";
>>> }else{
>>> print "false\n";
>>> }
>>
>> system is documented as returning -1 in case of an error on the way to
>> executing $cmd.
>
> Yes, but that works for me and returns true for $cmd = "/bin/true"; and
> false with $cmd = "/bin/false"
The problem is that it will return 'false' for $cmd = "/bin/ture"
despite the command couldn't be executed because of the (mock) typo and
the error code in $! would communicate that.
------------------------------
Date: Thu, 02 Apr 2015 15:29:00 -0700
From: "$Bill" <news@todbe.com>
Subject: Re: Backticks status in scalar context: bug or missunderstanding
Message-Id: <551DC2AC.9090401@todbe.com>
On 4/2/2015 06:55, Martin Str|mberg wrote:
>
> However, IMO, that part of the documentation is severly misleading. I'll
> quote part of it again:
>
> The collected standard output of the command is returned. ... In scalar
> context, it comes back as a single string, or undef if the command failed.
There is a difference between a command failing and one returning
null output.
> First it says uses "command" in the sense program executed, then the second
> "command" isn't the same command as the first but the act of forking and
> execing.
>
> I dare say, anyone reading this will assume the "undef if the command failed"
> will assume what I did and that `/bin/false` will return undef.
A command can either output something or nothing. I would assume
that true would output a '1' and false a '0', but one could also
assume they would output the string '1' or nothing/null. I doubt I
would ever assume it would output undef which is not a string. I
suppose you might argue that Perl would convert an output of nothing
into an undef, but the $var is defined (my $ret = `$cmd`;) and contains
nothing because nothing was output from false.
What's not obvious is that true/false don't actually output anything -
they just use the exit code to indicate success/failure.
my $cf = "C:/Dev/Cygwin/bin/false";
my $ct = "C:/Dev/Cygwin/bin/true";
foreach my $cmd ($cf, $ct) {
my $ret = `$cmd`;
if (defined $ret) {
print "$cmd ret defined.\n";
if ($ret) {
print "$cmd ret true ($ret) \$?='$?'\n";
} else {
print "$cmd ret false ($ret) \$?='$?'\n";
}
} else {
print "$cmd ret undefined. \$?='$?'\n";
}
}
__END__
C:/Dev/Cygwin/bin/false ret defined.
C:/Dev/Cygwin/bin/false ret false () $?='256'
C:/Dev/Cygwin/bin/true ret defined.
C:/Dev/Cygwin/bin/true ret false () $?='0'
I get a 'Command not found.' when there is no (or I misspell) /bin/false.
------------------------------
Date: Fri, 3 Apr 2015 17:47:21 +0000 (UTC)
From: "David Canzi" <dmcanzi@uwaterloo.ca>
Subject: Re: Backticks status in scalar context: bug or missunderstanding
Message-Id: <mfmjn9$vvf$1@rumours.uwaterloo.ca>
Martin Str|mberg <ams@luminous.ludd.ltu.se> wrote:
>Peter Makholm <peter@makholm.net> wrote:
>> Martin Str|mberg <ams@luminous.ludd.ltu.se> writes:
>
>> > Let me point out the part that is relevant:
>> >
>> > In scalar context, it comes back as a single string, or undef if the command
>> > failed.
>
>> The issue is the exact definition of 'failed'. I think that a more
>> complete description wpuld be 'or undef if the command failed to
>> execute'.
>
>> In your case the command did ran correctly, but it returned no output
>> and a status code of 1. If you want the status code you need to look at
>> the variable $? (specifically $? >>8, see 'perlvar -v '$?').
>
>> A filure would be if the command didn't exist, wasn't executable, or
>> that the execve system call failed for some other reason.
>
>Ok, that explains what is happening. If I try the command
>"/bin/false_does_not_exists", I do get undef.
Just to increase the confusion...
$o = `no-such-command x`
Result: $o is undefined.
$o = `no-such-command *`
Result: $o is defined.
--
David Canzi | "No single raindrop believes it is to blame for the flood."
| http://www.despair.com/irresponsibility.html
------------------------------
Date: Fri, 03 Apr 2015 19:54:24 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Backticks status in scalar context: bug or missunderstanding
Message-Id: <87bnj5avq7.fsf@doppelsaurus.mobileactivedefense.com>
"David Canzi" <dmcanzi@uwaterloo.ca> writes:
> Martin Str|mberg <ams@luminous.ludd.ltu.se> wrote:
>>Peter Makholm <peter@makholm.net> wrote:
>>> Martin Str|mberg <ams@luminous.ludd.ltu.se> writes:
>>
>>> > Let me point out the part that is relevant:
>>> >
>>> > In scalar context, it comes back as a single string, or undef if the command
>>> > failed.
>>
>>> The issue is the exact definition of 'failed'. I think that a more
>>> complete description wpuld be 'or undef if the command failed to
>>> execute'.
>>
>>> In your case the command did ran correctly, but it returned no output
>>> and a status code of 1. If you want the status code you need to look at
>>> the variable $? (specifically $? >>8, see 'perlvar -v '$?').
>>
>>> A filure would be if the command didn't exist, wasn't executable, or
>>> that the execve system call failed for some other reason.
>>
>>Ok, that explains what is happening. If I try the command
>>"/bin/false_does_not_exists", I do get undef.
>
> Just to increase the confusion...
>
> $o = `no-such-command x`
> Result: $o is undefined.
>
> $o = `no-such-command *`
> Result: $o is defined.
Well, of course it is (and the output you got should have told you why):
For the first case, Perl splits the command into words, forks and
invokes exec to execute the command directly. This results in an ENOENT
error (code 2)[*]. The second string-in-backticks contains a shell
metacharacter (the *), hence perl forks and invokes
sh -c "no-such-command *"
the shell fails to execute the command and returns an exit status which
is available in $?. $o contains an empty string in this case because the
shell didn't write any output to stdout.
[*] The error code is sent back to parent perl from the child perl via
pipe. The parent then sets $! accordingly and returns undef to indicate
this.
------------------------------
Date: Sat, 04 Apr 2015 12:07:39 +0200
From: gamo <gamo@telecable.es>
Subject: Does "exit" closes all filehandles?
Message-Id: <mfod5o$r77$1@speranza.aioe.org>
I wonder what could happen if not.
TIA
--
http://www.telecable.es/personales/gamo/
The generation of random numbers is too important to be left to chance
------------------------------
Date: Sat, 04 Apr 2015 03:26:10 -0700
From: "$Bill" <news@todbe.com>
Subject: Re: Does "exit" closes all filehandles?
Message-Id: <mfoe6i$ae2$1@dont-email.me>
On 4/4/2015 03:07, gamo wrote:
>
> I wonder what could happen if not.
I suppose if it didn't, the OS exit handler would. Can't imagine
it not. If it didn't it might not be all that bad - possibly a
slow memory leak - or just as easily - a disaster. ;)
What kind of OS would ever allow that to happen?
------------------------------
Date: Thu, 2 Apr 2015 10:43:27 -0500
From: "E.D.G." <edgrsprj@ix.netcom.com>
Subject: Re: Error Messages
Message-Id: <ZcqdnUZ7aN0C_oDInZ2dnUU7-TednZ2d@earthlink.com>
"Jürgen Exner" <jurgenex@hotmail.com> wrote in message
news:2aqrgatb5v5i4bhbu18rhrauio2lljit2l@4ax.com...
> Again, are you talking about program developement or about running a
> program in production?
These are largely research type computer programs that to a
considerable extent are intended to simply indicate in which direction some
project should be headed. Actual plant production programming should
probably always be carefully done.
The output data are the only important thing here. When they have
been generated the programs can often be discarded. So there is no reason
to spend a lot of time on trying to get them to look perfect.
This approach appears to be working quite well. From what I can
tell, one giant foreign government likes my data so much that they are now
planning on getting starting on the development of their own systems that
will duplicate my test procedures and data. In their case the data will be
collected and processed largely using electronic and mechanical systems
rather than the probability based computer programs I have developed. And
if they do go ahead with their plan they will likely be spending lots and
lots of money on the project. I have already contacted them and offered to
help them accelerate their efforts if they are interested.
Finally,
After what seems like months of effort my research colleague who is
converting my Perl code to Fortran has finally finished preparing the first
full program. And even without optimization it reduces calculation times by
a factor of more than 10.
Thanks to all for the helpful comments.
E.D.G.
------------------------------
Date: Thu, 02 Apr 2015 19:05:31 +0200
From: "G.B." <bauhaus@futureapps.invalid>
Subject: Re: One more reason I like Perl.
Message-Id: <mfjsr4$f14$1@dont-email.me>
On 02.04.15 14:26, Rainer Weikusat wrote:
> jt@toerring.de (Jens Thoms Toerring) writes:
>
> [...]
>
>> I'd rather not be an unsuspecting user of one of your programs;-)
>> A program that segfaults has a serious defect that must be cor-
>> rected.
>
> A program which segfaulted made an invalid memory access. There are a
> variety of possible causes for that, programm error, hardware problem or
> invalid input (precondition not satisfied).
Not everyone agrees that "invalid input" is subsumed under
"precondition not satisfied": When "precondition" is understood
to mean the conditions established strictly after
input checking, "input" of "I/O" is excluded: You'd start
reasoning about the steps of the algorithm given valid data,
and only when there are valid data.
The description of valid input data for substitute.perl---the
shortest of all possible descriptions, I might say--was perhaps
not for unsuspecting users?
> For the latter case, a
> sensible user interface should check whether arguments from outside the
> program make any sense[*] prior to trying to use them and should print
> intelligible error messages enabling correction of the problem but
> technically, this remains an operator error.
I beg to differ. It simply isn't the job of unsuspecting
operators to study the source text of the programs
they are supposed to run. If a tool is useful to one person,
the error would be to hand it to other unsuspecting users,
unchanged and without comment!
In any case, making the program open to other users of
the system offers them an opportunity to inject code (you've
mentioned 'heartbleed' since it was similar, I guess).
For example, varying this:
$ substitute.perl x 'while(1){}' e
I'd then find it odd to characterize 'heartbleed' as an operator
error, technically, following the above argument.
Or has 'heartbleed' been a feature of OpenSSL that "any competent
operator" would have known to avoid by studying the source?
An engineer might know how to operate his own marvelous machine.
Others might not. When they are still given the machine and should
operate it, then "unsuspecting" becomes a valid concern.
------------------------------
Date: Thu, 02 Apr 2015 19:14:52 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: One more reason I like Perl.
Message-Id: <87mw2qcs83.fsf@doppelsaurus.mobileactivedefense.com>
"G.B." <bauhaus@futureapps.invalid> writes:
> On 02.04.15 14:26, Rainer Weikusat wrote:
>> jt@toerring.de (Jens Thoms Toerring) writes:
>>
>> [...]
>>
>>> I'd rather not be an unsuspecting user of one of your programs;-)
>>> A program that segfaults has a serious defect that must be cor-
>>> rected.
>>
>> A program which segfaulted made an invalid memory access. There are a
>> variety of possible causes for that, programm error, hardware problem or
>> invalid input (precondition not satisfied).
>
> Not everyone agrees that "invalid input" is subsumed under
> "precondition not satisfied": When "precondition" is understood
> to mean the conditions established strictly after
> input checking, "input" of "I/O" is excluded: You'd start
> reasoning about the steps of the algorithm given valid data,
> and only when there are valid data.
A 'precondition' is a condition which has to be true prior to starting
to execute an algorithm for it to work as intended. Eg, this program
---------
#include <stdio.h>
#include <string.h>
int main(int argc, char **argv)
{
argv[1][strlen(argv[1]) - 4] = 'b';
puts(*argv);
puts(argv[1]);
return 0;
}
---------
will print argv[0] followed by argv[1] with the character 4 characters
in front of the end of argv[1] replaced by b provided an argv[1] whose
length is at least 4 was actually supplied (otherwise, its behaviour is
undefined).
[...]
>> For the latter case, a
>> sensible user interface should check whether arguments from outside the
>> program make any sense[*] prior to trying to use them and should print
>> intelligible error messages enabling correction of the problem but
>> technically, this remains an operator error.
>
> I beg to differ. It simply isn't the job of unsuspecting
> operators to study the source text of the programs
> they are supposed to run.
[...]
That's still not a program error, just lacking documentation.
> In any case, making the program open to other users of
> the system offers them an opportunity to inject code (you've
> mentioned 'heartbleed' since it was similar, I guess).
[...]
> I'd then find it odd to characterize 'heartbleed' as an operator
> error,
I didn't. I just mentioned this because "don't implement input validation" is a
very renowned academic/ scientifc practice and nobody was ever stripped
of his laurel wreath just because of that.
------------------------------
Date: Fri, 03 Apr 2015 00:02:25 -0400
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: One more reason I like Perl.
Message-Id: <551e10d1$6$fuzhry+tra$mr2ice@news.patriot.net>
In <lK6dnVtrAvk9YIHInZ2dnUVZ572dnZ2d@giganews.com>, on 04/02/2015
at 01:28 AM, Robbie Hatley <see.my.sig@for.my.address> said:
>Whereas in a non-interpreted language, the executable is run directly
>by the OS, so
There is no so. Compilers are perfectly capable of code to generate
decent error messsages, and run-time libraries can also do so.
>error messages are much more vague
Except when they aren't. I recall students using the PL/I "optimizing"
complier because for their problems the error messages were better
than the ones from the Checkout compiler.
>and don't specify what parts
>of the input or source code caused the error.
Except when they do.
>Especially since I set the compiler to strip-out the symbol table;
Gun, foo. Foot, gun.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Fri, 03 Apr 2015 21:10:22 +0200
From: Georg Bauhaus <bauhaus@futureapps.invalid>
Subject: Re: One more reason I like Perl.
Message-Id: <mfmoh8$fto$1@dont-email.me>
On 02.04.15 20:14, Rainer Weikusat wrote:
>> Not everyone agrees that "invalid input" is subsumed under
>> "precondition not satisfied":[...]
>
> A 'precondition' is a condition which has to be true prior to starting
> to execute an algorithm for it to work as intended.
> Eg, this program
>
> ---------
> #include <stdio.h>
> #include <string.h>
>
> int main(int argc, char **argv)
> {
> argv[1][strlen(argv[1]) - 4] = 'b';
> puts(*argv);
> puts(argv[1]);
>
> return 0;
> }
> ---------
>
> will print argv[0] followed by argv[1] with the character 4 characters
> in front of the end of argv[1] replaced by b provided an argv[1] whose
> length is at least 4 was actually supplied (otherwise, its behaviour is
> undefined).
Interesting twist. Redefines input as not input but as whatever happens
to have been put in^H^Hfor parameters to the program...
>> I'd then find it odd to characterize 'heartbleed' as an operator
>> error,
>
> I didn't. I just mentioned this because "don't implement input validation" is a
> very renowned academic/ scientifc practice and nobody was ever stripped
> of his laurel wreath just because of that.
This is worrisome. Do you have facts to back this up?
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 4407
***************************************
