[Libvir] [PATCH] Fix warn_unused_result when compiling with latest glibc
I'm not sure if this is the right way to solve this, but it is a way. Rich.
On Mon, Mar 26, 2007 at 03:39:51PM +0100, Richard W.M. Jones wrote:
I'm not sure if this is the right way to solve this, but it is a way.
we should test the return value to check for an error there, the unfortunate thing is that since we are in a signal handler there isn't much we can do, I suggest to increment a global variable (which could for example be checked if we hit that problem by some other code in the main loop). Other ideas ? Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Daniel Veillard wrote:
On Mon, Mar 26, 2007 at 03:39:51PM +0100, Richard W.M. Jones wrote:
I'm not sure if this is the right way to solve this, but it is a way.
we should test the return value to check for an error there, the unfortunate thing is that since we are in a signal handler there isn't much we can do, I suggest to increment a global variable (which could for example be checked if we hit that problem by some other code in the main loop). Other ideas ?
How about this patch. It implements your suggestion. Rich.
On Mon, Mar 26, 2007 at 04:22:33PM +0100, Richard W.M. Jones wrote:
Daniel Veillard wrote:
On Mon, Mar 26, 2007 at 03:39:51PM +0100, Richard W.M. Jones wrote:
I'm not sure if this is the right way to solve this, but it is a way.
we should test the return value to check for an error there, the unfortunate thing is that since we are in a signal handler there isn't much we can do, I suggest to increment a global variable (which could for example be checked if we hit that problem by some other code in the main loop). Other ideas ?
How about this patch. It implements your suggestion.
Looks good to me. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
On Mon, Mar 26, 2007 at 04:22:33PM +0100, Richard W.M. Jones wrote:
Daniel Veillard wrote:
On Mon, Mar 26, 2007 at 03:39:51PM +0100, Richard W.M. Jones wrote:
I'm not sure if this is the right way to solve this, but it is a way.
we should test the return value to check for an error there, the unfortunate thing is that since we are in a signal handler there isn't much we can do, I suggest to increment a global variable (which could for example be checked if we hit that problem by some other code in the main loop). Other ideas ?
How about this patch. It implements your suggestion.
yup, better than I would have done myself (didn't knew there was a specific type sig_atomic_t for atomic access...). Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Daniel Veillard wrote:
On Mon, Mar 26, 2007 at 04:22:33PM +0100, Richard W.M. Jones wrote:
Daniel Veillard wrote:
I'm not sure if this is the right way to solve this, but it is a way. we should test the return value to check for an error there, the unfortunate thing is that since we are in a signal handler there isn't much we can do, I suggest to increment a global variable (which could for example be checked if we hit that problem by some other code in
On Mon, Mar 26, 2007 at 03:39:51PM +0100, Richard W.M. Jones wrote: the main loop). Other ideas ? How about this patch. It implements your suggestion.
yup, better than I would have done myself (didn't knew there was a specific type sig_atomic_t for atomic access...).
Committed to CVS. Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 "[Negative numbers] darken the very whole doctrines of the equations and make dark of the things which are in their nature excessively obvious and simple" (Francis Maseres FRS, mathematician, 1759)
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
Richard W.M. Jones