Re: [Gnu-arch-users] Nit

[Dustin Sallings]

On Tuesday, Oct 21, 2003, at 20:37 US/Pacific, Andrew Suffield wrote:

> On Tue, Oct 21, 2003 at 08:13:29PM -0700, Dustin Sallings wrote:
> > > > > I have never even encountered a program where this was not true, 
> > > > > let
> > > > > alone written one.
> > > >
> > > >         Are you familiar with signal 13?  That's what your application
> > > > receives when its standard out goes to a pipe and the pipe closes.
> > > > The
> > > > default behavior is to have your program abort when it's unable to
> > > > produce any more output.
> > >
> > > Behaviour which is fortunately easy to turn off. What I said remains
> > > true, no matter how many historical features of unix you point out
> > > that make it inconvinient.
> >
> >         Oh come on.  You either haven't seen it, or it's historical and in
> > every application that hasn't specifically disabled it.
>
> I've seen it, and I've seen several applications that haven't disabled
> it, and it's been undesireable in every case, which is what I
> said. Where's your point?

	Well, at the top of this deeply quoted text, you hadn't seen it.  Now 
you have.

> >         I have seen very few applications, if any, that consider ENOSPC a
> > temporary error.  I have a lot of programs that write to disk.  That's
> > their job.  If there is no space, they cannot do their job.  What are
> > they supposed to instead?
>
> Wait for more space, usually.

	Can you cite an application (other than something you've written, 
apparently) where this actually happens?

> And yet you don't know how to acquire a list of all the perl
> primatives? Or generate it on the fly? Oh dear. You are the sort of
> person who gives perl a bad name. A skilled perl programmer would
> produce things like that without having to think about them.

	Yay, more personal insults rather than accepting that there's a 
problem.  And no, the problem is not how to generate a list of all perl 
primitives.  The problem is how to finish the Fatal implementation perl 
comes with.  It's another example of a half-complete piece of code that 
becomes increasingly difficult as you near completion due to 
inconsistencies.

	You'd be part of the way there if you narrowed its reaction down to 
only one of the two values perl considers false.  The rest is dealing 
with individual functions and their perception of failure.

> No, that is not the only goal. Raising an exception on every error
> might accomplish this, but it would have other disadvantages that are
> unnecessary. Hence, perl does not do this - particularly since that
> exact result can be generated fairly easily.

	You make it sound as if you sat through the meeting where they, um, 
``designed'' the error reporting for perl.  Are you sure perl returns 
undef rather than throws exceptions on error because of some defined 
disadvantages?

> > If
> > the most obvious and easiest way to solve a problem isn't the most
> > reliable, it's not going to be the most common.  Experience is
> > important here, of course, but saying stuff like, ``Ask a perl
> > programmer to write it for you,'' when the only way they have to make
>                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > functions safe is to know every function that is unsafe is certainly
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > not helping.
>
> Straw man. You just don't know how to do it properly (and I have
> better things to do than to write the code for you).

	That's fine, I don't want the code...even if you don't ``have to think 
about [it].''

> > > > > >         To say that 0 should not ever be a valid result from a function
> > > > > >         seems a little odd.
> > > > >
> > > > > Definitely not a perl programmer.
> >
> >         [yet another inconsistency in the perl core functions was here]
> >
> > > I didn't say there were no exceptions. I said they were very few in
> > > number. I also said they were trivial to wrap.
> >
> >         Right, by writing more code.  If Fatal were implemented properly, I
> > wouldn't have to know all of these exceptions to perl's consistency.
>
> Apples and oranges. You're complaining that Fatal, a module written to
> perform task X, does not perform task Y.

	Fatal, a module that was written to ``replace functions with 
equivalents which succeed or die,'' does not work for certain core 
functions, to be specific.

> That's not what you said. Here's what you said:
>
> > > > > >         To say that 0 should not ever be a valid result from a function
> > > > > >         seems a little odd.
>
> I did not say that 0 should not ever be a valid result from a function.
>
> Please refrain from constructing more straw men.

	Well, the archives are there, but you accused me of not being a perl 
programmer when I suggested 0 was a valid return value.

> >         It's part of the POSIX module.
>
> So it's not a perl function at all, it's a C function. Don't expect C
> functions to behave like perl functions.
>
> The whole point of POSIX is to be the thinnest reasonale wrapper
> possible around a bunch of C functions. It is very rarely necessary to
> use it; an experienced perl programmer should always check twice
> before calling a function from POSIX, because there's probably a perl
> version that's preferable.

	Yes, as is clearly stated in the POSIX perldoc...somewhere between the 
parts where it says it gave them ``perl-ish interfaces'' and ``It's a 
great source of wisdom.''

> > > Nobody who is remotely used to using java is going to expect
> > > well-written java code, especially from third parties.
> >
> >         That answer is a bit rhetorical and probably just as true without
> > specifying a language.
>
> Yes, that was my point, which you have "conviniently" deleted from the
> quoted text.

	Ahhh, this must be why you keep accusing me of not reading what you're 
writing.  Clearly some pieces aren't making it across, as those were 
the only two lines anywhere near this part of the message that came 
from you.

--
SPY                      My girlfriend asked me which one I like better.
pub  1024/3CAE01D5 1994/11/03 Dustin Sallings <address@hidden>
|    Key fingerprint =  87 02 57 08 02 D0 DA D6  C8 0F 3E 65 51 98 D8 BE
L_______________________ I hope the answer won't upset her. ____________