[GRASS5] Problem with r.fill.dir

[Michel Wurtz]

"Eric G. Miller" wrote:
> 
> On Fri, May 11, 2001 at 01:45:05PM +0700, Justin Hickey wrote:
> > Hi Roger
> >
> > When compiling the r.fill.dir program on an SGI with MIPSPro compilers I
> > get the following error:
> >
> > "main.c", line 52: error(1005): could not open source file "error.h"
> >   #include <error.h>
> 
> I think we've seen this before (as I tried to use the same thing once).
> A good substitute for error() is strerror(), but it may not be supported
> everywhere yet ;(.

But if you exit after the error message, why not use the grass function
G_fatal_error() ?

> > Since the comment for this include statement is associated with lseek,
> > can you change lseek to fseek? There are other reasons for using fseek
> > as well. First, fseek is a standard library function and lseek is not.
> > Second, according to Kernighan and Ritchie's "The C Programming
> > Language", lseek can have slower access. Thus, I would suggest changing
> > lseek to fseek if possible. Then the error.h file may not be needed.
> >
> > Just my 2 cents worth.
> 
> lseek and fseek aren't interchangeable; one works with descriptors the
> other works with streams.  I don't know why lseek would have slower
> access. My understanding is a file stream on *nix typically has a file
> descriptor in the FILE struct, so a call to fseek is probably just
> translated to a call to lseek.  As far as standards, lseek should exist
> on every *nix system (is it POSIX?) and is used all over GRASS library
> code.  While the FILE stream interface may be more portable via ANSI C,
> the *nix file descriptor interface is generally more flexible.  I'm not
> necessarily arguing one over the other, but we shouldn't kid ourselves
> as GRASS is heavily entrenched in *nix standards.

The reason why lseek is generaly slower than fseek is that streams are
bufferised, so fseek may just update a pointer, without calling lseek.
fseek is a subroutine, which is also faster than a system call like lseek.
lseek is a direct move at disk level.  I believe lseek doen't do anything
else than pointing actually.  It is the subsequent read that will really
move the heads and read physically the disk. If you are lucky, the disk block
pointed is still in the kernel buffers, and the overhead is very low. This
is often the case with Linux, thanks to the dynamic buffer space allocation.

--
Michel WURTZ - DIG - Maison de la télédétection
               500, rue J.F. Breton
               34093 MONTPELLIER Cedex 5

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'