Compilation errors on Ubuntu 8.10 Intrepid Ibex
eric_a_benson at yahoo.com
Tue Nov 11 10:25:11 MSK 2008
Yes, this works. In fact, after you change it from a macro to a static function you don't need a cast to void. So, changing the header file is sufficient.
I can see the argument for continuing to serve pages even if the log filesystem is full. I have experience with the opposite case. It all depends on how critical the logs are for a business. Having been at Amazon.com in 1996 and 1997 I can tell you that there were times when we were able to reconstruct some customer transactions using web server logs after databases were damaged. If it were up to me, I would at least want this to be a configuration option.
----- Original Message ----
From: Igor Sysoev <is at rambler-co.ru>
To: nginx at sysoev.ru
Sent: Monday, November 10, 2008 10:35:36 PM
Subject: Re: Compilation errors on Ubuntu 8.10 Intrepid Ibex
On Mon, Nov 10, 2008 at 02:27:43PM -0800, Eric Benson wrote:
> Whether it is gcc's bug because cast to void does not suppress the compiler warning, or it is glibc's bug because it declares write() with attribute warn_unused_result, you are unlikely to see a change from either in the near future. The best course is to take it as an opportunity to do some paranoid error checking in these cases. In most cases, there is some better action to be taken when write() fails. In the worst case, such as trying to write a log entry to a full file system, it is better to exit() with non-zero status than to silently continue running. This is why the attribute was added to the declaration of write(). Most projects do not use -Werror, so they only see added compiler output instead of termination of the build process. I agree that it seems like an awfully big change that might adversely affect many mature software projects. However, there is virtually no case when it is correct to ignore an exceptional condition in write().
I believe, that many prefer that server continues to serve site even its log
filesystem is full. So there is no way how to handle write() error while
logging another error except to ignore it.
Here is the new preliminary patch to test work-around.
More information about the nginx