Re: [Gnu-arch-users] Nit

[Andrew Suffield]

On Tue, Oct 21, 2003 at 01:49:44PM -0700, Dustin Sallings wrote:
> 
> On Tuesday, Oct 21, 2003, at 10:52 US/Pacific, Andrew Suffield wrote:
> 
> >>    I'm not talking about error recovery, I'm talking about error
> >>trapping.  printf() is a write() call as far as I'm concerned.
> >
> >I disagree with this equivalence very strongly, which is why printf()
> >is one of the few calls which I don't bother to check the result
> >of. fprintf(stderr, ...) is another.
> 
>       Are you saying you make assumptions about particular file 
>       descriptors?

Yes. I assume that stdio behaves like stdio, that sockets behave like
sockets, and so on. You can find many of these assumptions documented
in POSIX, and many more which aren't really documented anywhere.

> >These are special because they are stdio.
> >
> >In the case of a permanent error, the stream will be marked as closed
> >and further printf() calls will return rapidly, probably without
> >calling write() at all.
> >
> >In the case of a temporary error, the data will go into the buffer and
> >be unloaded later when the output stream is ready again.
> >
> >In neither of these cases do I want to waste space in my program with
> >handling of these errors, because they already do exactly what I want
> >them to do.
> >
> >In neither of these cases do I want my program to abort.
> >
> >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.

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

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.

> >>    I think this is a good example of exceptions making it easier to
> >>    write more reliable software.  If printf() would just fail if it 
> >>couldn't
> >>do what you asked it to do, your code would stop running when you ran 
> >>out
> >>of disk space (unless you trapped it and wanted to do something
> >>different).
> >
> >It would be really amazingly stupid for your program to fail just
> >because somebody closed stdin. I can't believe you are seriously
                           ^^^^^

Should have been stdout. Actually, it should probably have been
stderr, it's especially true there.

> >suggesting that. This would be considered a serious bug in pretty much
> >any unix program.
> 
>       I was referring to stdout, but do you consider the same true for 
> stdin?  If the program wants to read from stdin, and there is no stdin, 
> should the program continue to try to read from stdin?  If so, how is 
> this different?

It's different in that printf() and fprintf() already do the right
thing. I said that already.

Actually, so do scanf() and fscanf(), but those should generally be
avoided for other reasons, so you generally use read() for stdin.

> >>    But it doesn't, and it's not automatic, and I don't know the list,
> >>    and I won't necessarily know when they add one, etc...
> >
> >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.

> >>    To say that 0 should not ever be a valid result from a function
> >>    seems a little odd.
> >
> >Definitely not a perl programmer.
> 
>       Does perl not have non-blocking IO, or are read and syswrite just 
> guaranteed to never return 0 under any circumstances?  Actually, let's 
> look in the docs:
> 
> dustin2wti:/Volumes/Untitled 566% perldoc -f read
>        read FILEHANDLE,SCALAR,LENGTH,OFFSET
> 
>        read FILEHANDLE,SCALAR,LENGTH
>                Attempts to read LENGTH bytes of data into vari-
>                able SCALAR from the specified FILEHANDLE.
>                Returns the number of bytes actually read, `0' at
>                end of file, or undef if there was an error.
>                SCALAR will be grown or shrunk to the length actu-
>                ally read.  An OFFSET may be specified to place
>                the read data at some other place than the begin-
>                ning of the string.  This call is actually imple-
>                mented in terms of stdio's fread(3) call.  To get
>                a true read(2) system call, see `sysread'.
> 
>       Here, it says undef is returned for error, and 0 is a valid result 
> saying that you've reached EOF.  Fatal does not distinguish.

I didn't say there were no exceptions. I said they were very few in
number. I also said they were trivial to wrap.

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

> >>    I didn't say that.  Consider mktime.  It may return either 0 or
> >>    undef. 0 is success, undef is an error.  Both will cause an 
> >>exception to
> >> be thrown from Fatal.
> >
> >That's a C function. Not a perl one.
> >
> >The perl equivalent is Time::Local::timegm. It's not a core function,
> >so it's not relevant to Fatal. Particularly since it already throws an
> >exception on error.
> 
>       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 may not be the one of many tools you use for constructing epoch 
> time, but it's the one that I've known of the longest.  If it's not 
> appropriate, they should pull it.

I have no idea what you were looking at. Probably some extension
module. Time::Local has been part of the core for a long time.

> >>    Especially java?  All of the core java stuff throws exceptions when
> >>there's an error (I'm sure there's at least one exception somewhere).
> >
> >Did you *read* what I said? If I had meant core stuff, I would have
> >said "core stuff". I clearly said "library modules".
> >
> >There is no end of class libraries for java which have poor or no
> >error handling mechanisms, and there's a whole bunch more (mostly JNI
> >stuff) that use errno-like mechanisms instead of exceptions.
> 
>       Yeah, I did, and I was trying to make sense of it.  You said this is 
>       a problem especially in java.  Java has conventions for doing things 
> that 
> experienced java developers adopt (i.e. the kind who make libraries and 
> stuff).  The java way is to use exceptions.  Nobody who is remotely 
> used to using java is going to expect anything else.

Nobody who is remotely used to using java is going to expect
well-written java code, especially from third parties.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

signature.asc
Description: Digital signature