The file /lib/vector/diglib/test.c fails on Solaris. Under Solaris, you
cannot perform a write immediately after a on the same file without
performing fflush(fp) in between or closing and reopening the file.
Here is the diff output:
66a67
fflush(fp);
79a81
fflush(fp);
93a96
fflush(fp);
107a111
fflush(fp);
121a126
fflush(fp);
134a140
fflush(fp);
On Sat, Mar 01, 2003 at 10:26:28AM -0800, cheg01@attbi.com wrote:
The file /lib/vector/diglib/test.c fails on Solaris. Under Solaris, you
cannot perform a write immediately after a on the same file without
performing fflush(fp) in between or closing and reopening the file.
Theoretically, this is true of any C FILE stream. If opened for reading
and writing one must at least perform fflush or a file positioning
function (fseek/ftell/rewind/fgetpos/fsetpos) if changing between
reading and writing. Many systems handle the change transparently,
though they are not required to do so.
--
echo ">gra.fcw@2ztr< eryyvZ .T pveR" | rot13 | reverse
On Saturday 01 March 2003 07:26 pm, cheg01@attbi.com wrote:
The file /lib/vector/diglib/test.c fails on Solaris. Under Solaris, you
cannot perform a write immediately after a on the same file without
performing fflush(fp) in between or closing and reopening the file.
Thanks for this information. I fixed that in test.c but the problem
remains in the library.
If the vector is opened for update Vect_open_update() and new line is written
Vect_write_line()(calls fflush()) and read by Vect_read_next_line() or
Vect_read_line() (do not call fflush()) next call to Vect_write_line() should
fail, is it right? Can you give any recommendation where to add fflush().
I think that before fwrite() in Vect_write_line().
I would highly appreciate if you could test if vector binaries
are realy portable between more platforms (write on one and read on
another). I have never tested any other than intel. Could you send me
grass51/dist.$(ARCH)/include/portable.h? Just for my collection.
Radim
If the vector is opened for update Vect_open_update() and new line is
written Vect_write_line()(calls fflush()) and read by Vect_read_next_line()
or Vect_read_line() (do not call fflush()) next call to Vect_write_line()
should fail, is it right? Can you give any recommendation where to add
fflush(). I think that before fwrite() in Vect_write_line().
On Saturday 01 March 2003 08:54 pm, Eric G. Miller wrote:
Theoretically, this is true of any C FILE stream. If opened for reading
and writing one must at least perform fflush or a file positioning
function (fseek/ftell/rewind/fgetpos/fsetpos) if changing between
reading and writing. Many systems handle the change transparently,
though they are not required to do so.
Vect_write_line() starts by fseek(), so is it OK?
Radim
----- Original Message -----
From: "Radim Blazek" <blazek@itc.it>
To: <cheg01@attbi.com>; "grass5 developers list" <grass5@grass.itc.it>
Sent: Monday, March 03, 2003 5:13 AM
Subject: Re: [GRASS5] Non-portable code in 5.1 portability test
Thanks for this information. I fixed that in test.c but the problem
remains in the library.
If the vector is opened for update Vect_open_update() and new line is
written
Vect_write_line()(calls fflush()) and read by Vect_read_next_line() or
Vect_read_line() (do not call fflush()) next call to Vect_write_line()
should
fail, is it right? Can you give any recommendation where to add fflush().
I think that before fwrite() in Vect_write_line().
You could do it either after the fread() or before the fwrite(). It makes
sense from a symetery point of view to end both functions with an
fflush(fp) so that it doesn't have to fflush twice on every fwrite() call.
I would highly appreciate if you could test if vector binaries
are realy portable between more platforms (write on one and read on
another). I have never tested any other than intel. Could you send me
grass51/dist.$(ARCH)/include/portable.h? Just for my collection.
I will try that once I get 5.1 running on the first platform. I still
haven't completed a build.
Radim
_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5
portable.h (729 Bytes)
On Mon, Mar 03, 2003 at 02:34:46PM +0100, Radim Blazek wrote:
> If the vector is opened for update Vect_open_update() and new line is
> written Vect_write_line()(calls fflush()) and read by Vect_read_next_line()
> or Vect_read_line() (do not call fflush()) next call to Vect_write_line()
> should fail, is it right? Can you give any recommendation where to add
> fflush(). I think that before fwrite() in Vect_write_line().On Saturday 01 March 2003 08:54 pm, Eric G. Miller wrote:
> Theoretically, this is true of any C FILE stream. If opened for reading
> and writing one must at least perform fflush or a file positioning
> function (fseek/ftell/rewind/fgetpos/fsetpos) if changing between
> reading and writing. Many systems handle the change transparently,
> though they are not required to do so.Vect_write_line() starts by fseek(), so is it OK?
Should be sufficient.
--
echo ">gra.fcw@2ztr< eryyvZ .T pveR" | rot13 | reverse