[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[PATCH 0/3] tools: address recently reported Coverity issues
- To: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Thu, 18 Aug 2022 16:03:50 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=IUN7vaVh4r0dNBLCu3MEChinXPaRDFLZVXmbgnSuXxQ=; b=eoACjnoVXu2VylTd0AKfJ6S1Z2d6rim1BIjwnsyBn+JtCimmkGBUwEcKKHvGuObK0YU7E105awxCv2HPwajjPMFK2PWu3p7Z/vMGlbrqr8LawvlJdO9aYi1/XVvZigpPKpNmFA42AF/8fEV1LK3xnljoMqtIiJQy/pd33eLZSvW0+vZE3K+GLU6YRq+jpYgrx0KDXRFQ+VIHXdZ3TJ7jBSx/pqlKNH80eYM+DpzuhgAYUv/fVcApvC2mk04tYPYtDzj6i7bGnaow7BDx/VSb15/0z+CWeZrq6OBvOv18t9WxZBYGQnHuv89y/SwQf9oE1xK38M2sFIM3DHeOLfWfgg==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TmI0hFwBkWwtcrwHADXrmLP2LwcqXJlBm4rQWOcOJbRhXatGLmw3s8nGxGT163R+XN9R+uslmEgmymlbKaVpiZz0VMXdw7nfMOIAHKR1g8TkLVj2nZAx2cAubadd2t1Zve1HLBRPFwtNqFEiWMVCjJSxyaO6xRRnnnIc7t5kuD63rR1B3W9vuwIPqtmFP4ntahBrBXvSFXHVFOf26v8tmzozWYpdElDDBrnnj01M0rEub5nvgRQXf+W+E0VeiWkb5Ltf7ON28XjB3SjJSqHzkxAiuGkYQ2jXoerRREl3svR1s8FH7fxU1iVOfzLDG/gfd1CX0aiUL/j1gDQy5TyGqg==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: Anthony Perard <anthony.perard@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>
- Delivery-date: Thu, 18 Aug 2022 14:04:23 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
Three of the four reported issues a pretty clear how to take care
of, which is done in this series. The 4th, CID 1509375, isn't as
obvious, mainly because I don't know enough about Coverity to be
able to tell whether adding a cast there might help; the issue
reported for xenbaked suggests it wouldn't. The alternative I can
see would be an arch-independent piece of inline assembly, hiding
the transformation from time_t to int from the analysis tool. But
I'm not convinced such would be liked. Nor am I sure the can be
fully arch-ignorant, as time_t potentially being a 64-bit type
might not be possible to match with an "r" constraint on all 32-
bit architectures. So maybe what's left is memcpy() from a
"time_t" variable to an "int" one ...
1: xenbaked: properly use time_t in dump_stats()
2: console/client: properly use time_t in get_pty_fd()
3: libxl: use time_t for qmp_synchronous_send()'s last parameter
Jan
|
