On Tue, Oct 18, 2011 at 9:03 AM, Kevin Grittner <kevin.gritt...@wicourts.gov> wrote: > Jeff Davis wrote: > >> I'm not sure if these can/should be fixed or not, but here are the >> compiler warnings I'm getting on gcc and clang on ubuntu 11.10 with >> -O2. > >> elog.c: In function ‘write_pipe_chunks’: >> elog.c:2479:8: warning: ignoring return value of ‘write’, declared >> with attribute warn_unused_result [-Wunused-result] >> elog.c:2488:7: warning: ignoring return value of ‘write’, declared >> with attribute warn_unused_result [-Wunused-result] >> elog.c: In function ‘write_console’: >> elog.c:1797:7: warning: ignoring return value of ‘write’, declared >> with attribute warn_unused_result [-Wunused-result] > >> common.c: In function ‘handle_sigint’: >> common.c:247:4: warning: ignoring return value of ‘write’, declared >> with attribute warn_unused_result [-Wunused-result] >> common.c:250:4: warning: ignoring return value of ‘write’, declared >> with attribute warn_unused_result [-Wunused-result] >> common.c:251:4: warning: ignoring return value of ‘write’, declared >> with attribute warn_unused_result [-Wunused-result] >> In file included from mainloop.c:425:0: > > These we are getting only because of a stubborn insistence on coding > to the current implementation rather than the API. It's not that > much code to code to the API instead. I've already offered to > provide the (trivial) patch for this if there is buy-in on the idea > of coding to the API. > > The argument against is that no implementer of the API would ever > exercise the freedom the documented API gives them to do *part* of a > write to disk and return to the caller the number of bytes written > and then allow a subsequent write request to continue the output. I > think that the rise of virtual machine environments in big shops > provides a fairly obvious reason someone might want to do that.
Even if all we got out of it was that the compiler warnings went away, I think that would still be a sufficient reason to do it. And I tend to agree with you that the warnings are legit; and defending against them is virtually free. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
