[GRASS5] Problem with r.fill.dir

GRASS GRASS developer
1

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>

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.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

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

2

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

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.

--
Eric G. Miller <egm2@jps.net>

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

3

"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@geog.uni-hannover.de with
subject 'unsubscribe grass5'

4

On Fri, 11 May 2001, 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>

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.

Justin,

Thanks for the pointer. The direct solution here is to remove the line
that includes error.h. I thought I did that before the copy went to CVS,
but I guess I didn't. <error.h> was originally included to check on a
condition that never occured, so I removed the check. <error.h> isn't
needed in the current version.

Markus, would you be so kind as to remove the reference to error.h? For
some reason my DNS seems unable to find you this morning. My mail
directly to you bounced immediately.

The code is written to use open, read, write, and lseek, (all POSIX) and I
don't think I can switch lseek to fseek (ANSI) without changing all the
other references to their ANSI counterparts. If there are ongoing
problems, then I'll do it, but then the same change will be needed in a
lot of the rest of the GRASS code.

Roger Miller
Lee Wilson and Associates

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

5

On Fri, May 11, 2001 at 09:57:08AM -0600, Roger S. Miller wrote:

On Fri, 11 May 2001, 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>
>
> 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.

Justin,

Thanks for the pointer. The direct solution here is to remove the line
that includes error.h. I thought I did that before the copy went to CVS,
but I guess I didn't. <error.h> was originally included to check on a
condition that never occured, so I removed the check. <error.h> isn't
needed in the current version.

Markus, would you be so kind as to remove the reference to error.h? For
some reason my DNS seems unable to find you this morning. My mail
directly to you bounced immediately.

Roger,

I have removed the <error.h> in CVS.

The code is written to use open, read, write, and lseek, (all POSIX) and I
don't think I can switch lseek to fseek (ANSI) without changing all the
other references to their ANSI counterparts. If there are ongoing
problems, then I'll do it, but then the same change will be needed in a
lot of the rest of the GRASS code.

Maybe you could fix the problems on CRAY I have mailed personally to you
(all the same style of error). Then all platforms/compilers should be
satified.

Thanks,

  Markus

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

6

Hi Roger

"Roger S. Miller" wrote:

Thanks for the pointer. The direct solution here is to remove the
line that includes error.h. I thought I did that before the copy
went to CVS, but I guess I didn't. <error.h> was originally included
to check on a condition that never occured, so I removed the check.
<error.h> isn't needed in the current version.

It compiles fine on SGI's now.

The code is written to use open, read, write, and lseek, (all POSIX)
and I don't think I can switch lseek to fseek (ANSI) without changing
all the other references to their ANSI counterparts. If there are
ongoing problems, then I'll do it, but then the same change will be
needed in a lot of the rest of the GRASS code.

Sorry, it was my problem here. It's been a while since I wrote low-level
I/O programs and I did not recognize lseek. I thought that the use of
lseek required the inclusion of a non-standard header file (error.h),
so, I looked it up in my C book which does not mention POSIX and as a
result, made my suggestion in my previous mail. However, since it is
POSIX I retract my original suggestion.

Thanks for the fix.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

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