Re: [Gnu-arch-users] Nit

[Dustin Sallings]

On Tuesday, Oct 21, 2003, at 18:04 US/Pacific, Andrew Suffield wrote:

	This is getting off-topic even for an off-topic thread.  It's clear 
that we all have different ideas about error handling down to defining 
what an error is.

	To drift a little towards topic, I think it's rather nice to see how 
few actual arch problems are being discussed on the list.  I've 
successfully converted many years worth of CVS myself and am hoping to 
get some kind of bidirectional synchronization with the perforce server 
at work so I can work offline more.

        anyway...

> > > 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.

> >         Are you suggesting that it's OK to abort if you're no longer able to
> > write output to a consumer process, but not OK to abort if you're no
> > longer able to write output to a filesystem?
>
> Why are you not reading what I have written?
>
> ENOSPC is not a fatal error. It is a temporary error. It is not
> appropriate to abort when it occurs, regardless of whether you are
> writing to a pipe or to a file.

	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?

	Does tla call up Tom and ask him to come over to my house and free up 
disk space when it can't do a commit?

> Also, why do you keep assuming that the sole purpose of the program is
> to write to stdout? It is not appropriate for any program to abort
> when its logging mechanism fails, whether that is stdout or a file.

	Because that is the sole purpose (or at least an extremely vital part) 
of many, many programs I use every day.  You know, things like grep, 
dd, gzip, tar, find, diff, etc...  For example:

dustinti:/Volumes/Test 516% dd if=/dev/zero | gzip -1vc > test.out.gz

gzip: stdout: No space left on device

	If you're talking about logging, though...  In many of my 
applications, it is extremely undesirable for the application to 
proceed without logging what it's doing for accounting reasons.  If it 
can't log it, I can't audit it and I shouldn't do it.

> > > > Then you're not a perl programmer. QED.
> > >
> > > Ask a perl programmer to write it for you.
> >
> >         Well that sounds like an intelligent solution.  I'm talking about
> > 	ways to make it easier for everyone to write reliable software and 
> > you're
> > suggesting someone else should do who knows all the secrets of a
> > particular language.  Got it.
>
> Please be serious. It is not possible for "everyone" to write reliable
> software. Only programmers skilled in using the tools available are
> capable of writing reliable software.
>
> You are clearly unexperienced in using perl; you should not expect to
> get the same degree of flexibility that a serious perl programmer
> would.

	My last company had on average one hundred programmers working on 
about two million lines of perl.  I was the guy they called in to solve 
the ``hard problems.''  I did all the kinds of stupid hacks like I 
consider Fatal to be.  I've seen just about everything that can go 
wrong in a perl application and fixed it.

	The point isn't who's the better perl programmer, it's how can we make 
tools that make it easier for people to write more reliable code.  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.

> > > >         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.

> Please respond to things I actually said, not to things you would like
> to think I said.

	That statement is a little revisionist.  You're telling me I'm not a 
perl programmer because I think that 0 is a perfectly valid result from 
a function.  I provide examples and you say I'm not responding to 
things you said.  There clearly is a communication gap here.

> >         I got it from my perldoc:
> >
> >        mktime  Convert date/time info to a calendar time.
> >
> >                Synopsis:
> >
> >                        mktime(sec, min, hour, mday, mon, year, wday =
> > 0, yday = 0, isdst = 0)
>
> Well, I got:
>
> No documentation for perl function `mktime' found

        It's part of the POSIX module.

> 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.

--
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. ____________