Re: Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit. - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit.
Date
Msg-id 4D5D015D020000250003ABA5@gw.wicourts.gov
Whole thread Raw
In response to Re: Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit.  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit.
List pgsql-hackers
Tom Lane <tgl@sss.pgh.pa.us> wrote:
> In at least some of these cases, I think ignoring the write()
> result is intentional, because there's really nothing useful we
> can do about it if it fails (oh, you wish we'd log a failure to
> write to the log?).
I know that in Java you can get a positive number less than the full
size as an indication that part of the block was written, and you
must loop to write until you get all of it written (or get an error
return).  At this page, it appears that the same is true of the
write function in C:
http://www.gnu.org/s/libc/manual/html_node/I_002fO-Primitives.html
Quoting from that page:
| The return value is the number of bytes actually written. This may
| be size, but can always be smaller. Your program should always
| call write in a loop, iterating until all the data is written. 
Isn't that the write function we're calling?  If so, are you
maintaining that the gnu.org documentation of this function is
wrong?
-Kevin


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Debian readline/libedit breakage
Next
From: Bruce Momjian
Date:
Subject: Re: Debian readline/libedit breakage