Re: Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit.

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit.
Дата
Msg-id 4D5D015D020000250003ABA5@gw.wicourts.gov
обсуждение исходный текст
Ответ на Re: Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit.  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Re: [COMMITTERS] pgsql: Fix blatantly uninitialized variable in recent commit.  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: Debian readline/libedit breakage
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Debian readline/libedit breakage