similar to: Coverity: possible false positive in do_lxattrlist

http://git.annexia.org/?p=libguestfs.git;a=blob;f=daemon/debug.c;h=cd3e8a5f0294a910782b38552d2b0757869f862c;hb=HEAD#l430 Coverity complains about the error path from posix_memalign (lines 477-482) saying that 'buf' will be leaked. However my reading of the posix_memalign man page is that if the return value from posix_memalign != 0 then 'buf' would not have been allocated. Rich.

Hello, This patch allows userspace tools on a domU to setup a watch on the xenstore. It does this by intercepting XS_WATCH requests written to /proc/xen/xenbus and then re-submitting the request to the in-kernel xenstore interface, in linux-2.6-xen-sparse/drivers/xen/xenbus/xenbus_xs.c. When a callback occurs, an in-kernel function is invoked, which then reconstructs a response in the format

From: "Richard W.M. Jones" <rjones at redhat.com> Since we copy dirname + "/" + path to a fixed buffer of size PATH_MAX, we need to check that the buffer cannot overflow. --- helper/appliance.c | 16 ++++++++++++---- 1 files changed, 12 insertions(+), 4 deletions(-) diff --git a/helper/appliance.c b/helper/appliance.c index c4d0b32..05ad3e5 100644 ---

This patch cleans up some 80-odd warnings I was seeing when compiling the xenpci driver, all completely trivial. It also replaces the use of asm for calling cpuid with the __cpuid compiler intrinsic, and modifies calling code accordingly. I''m pretty sure my mailer going to mangle the inline patch (below) so I''m attaching the pristine version. (will try to fix for next time) --

Hi, I have come across a couple of cases where the code generated after CodeGenPrepare pass has "br i1 false .." with both true and false conditions preserved and this propagates further and remains the same in the final assembly code/executable. In CodeGenPrepare::runOnFunction, ConstantFoldTerminator (which handles the br i1 false condition) is called only once and if after the

Hi, I'm not subscribed, so keep me in cc. And thanks for having mailing-list open for posting. I had a couple of problems with OpenSSH on Solaris 8/MU3 + recent patches. 1) When I tried to use scp from any other host, sshd on Solaris host crashed with SIGSEGV. Here's the stack trace: core 'core.sshd.7637' of 7637: ./sshd -d -d -d fefb393c strncpy (ffbee074, 5, 7, 0,

Hi everyone I would like to enable unprivileged users to share only certain directories using SFTP without acquiring root, without setting capabilities using public-key-based forced commands. In another use case unprivileged users could write scripts that evaluate "$SSH_ORIGINAL_COMMAND" and then either execute sftp-server in a jail "$SSH_ORIGINAL_COMMAND" after

Extend the guestfs_inspect_list_applications2 API call to work on Arch Linux guest images. Signed-off-by: Nikos Skalkotos <skalkoto@gmail.com> --- src/inspect-apps.c | 137 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 137 insertions(+) diff --git a/src/inspect-apps.c b/src/inspect-apps.c index 6fb9665..8e645b7 100644 --- a/src/inspect-apps.c +++

A line was added to call `R_SetParams ` in the function `R_SetWin32` 4 days ago. https://github.com/wch/r-source/blob/2370eca96267e29a69396ef53a52ff5d6f60c65b/src/gnuwin32/system.c#L780 However, `R_SetParams` actually calls `R_SetWin32`. https://github.com/wch/r-source/blob/30f7698e19fe1d2ce8fe53d85cd6cfad21fc8bb0/src/main/startup.c#L284 So it results in a stack overflow. Related commit by Luke

On Sun, Nov 16, 2014 at 03:24:16PM +0200, Nikos Skalkotos wrote: > Extend the guestfs_inspect_list_applications2 API call to work on Arch > Linux guest images. Generally looks good. I have a few minor comments inline below. But also I think we could use a test case (see tests/guests/). I don't think we'd reject the patch for not having a test case, but the test case would ensure

Hi Michal 2012/1/10 Michal Hlavinka <mihl-guest at alioth.debian.org> > Author: mihl-guest > Date: Tue Jan 10 09:10:04 2012 > New Revision: 3383 > URL: http://trac.networkupstools.org/projects/nut/changeset/3383 > > Log: > Creating a branch for Coverity reported problems > I'm very interested there! Have you been able to get NUT part of the Coverity Scan

Not sure the semantics of "used" you propose is sufficient. AFAIU the proposal, "used" could only be used in cases where the function will always trigger UB if poison is passed as argument. The semantics of attributes is usually the other way around, since function calls need to have UB as strong as the worst behavior of the function. If a function may for some reason trigger

Extend the guestfs_inspect_list_applications2 API call to work on Arch Linux guest images. --- src/inspect-apps.c | 125 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 125 insertions(+) diff --git a/src/inspect-apps.c b/src/inspect-apps.c index b62b432..b7a3b0e 100644 --- a/src/inspect-apps.c +++ b/src/inspect-apps.c @@ -60,6 +60,7 @@ static struct

Hi Johannes, >> Not sure the semantics of "used" you propose is sufficient. AFAIU the >> proposal, "used" could only be used in cases where the function will >> always trigger UB if poison is passed as argument. The semantics of >> attributes is usually the other way around, since function calls need >> to have UB as strong as the worst

OK, I'll make the suggested changes and I'll try to come up with a new patch by tomorrow or the day after tomorrow. I just noticed that a space is missing between STREQ and ( in the key assignment code which violates the project's coding style. I'll fix that too. For a test-case, I can write a make-archlinux-img.sh script and send it in another patch. It's not big deal.

Hello, What intrinsics "@llvm.lifetime.start/@llvm.lifetime.end" really do? As per my knowledge, they define the live ranges of variables. In the following code section, they seem redundant. However, when I remove them, the behavior of the code becomes non-deterministic. The live ranges of the variables defined by them are never used in the code. Thanks, --------------- %37 = bitcast

----- Original Message ----- > From: "Michael Kuperstein" <michael.kuperstein at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Sanjay Patel" <spatel at rotateright.com>, "llvm-dev" > <llvm-dev at lists.llvm.org>, "Michael Kuperstein" <mkuper at google.com> > Sent: Thursday, December 15, 2016

By the way, I've been wondering - why can we only attach !nonnull and !range to loads (for both) and call/invoke (for !range)? I mean, those are all instructions you can't do dataflow through - intraprocedurally, w/o memoryssa - but why only these instructions? Why not allow annotating any pointer def with !nonnull and any integer def with !range? Sure, that's redundant w.r.t

I think what Sanjay is getting at is that it's not an integer, it's still a pointer - but it's not clear where information about non-nullness of the pointer should be propagated to. In this particular case, since the def of %x in the caller is also an argument, we could propagate it to the def directly, e.g. define i1 @foo(i32* nonnull %x) { %y.i = load i32, i32* %x ; inlined,

The general idea to date has been only "sources" get annotations. If there's something we fundamentally *can't* analyze through, that's where we annotate. We try not to use annotations for places where we could have but didn't. e.g. call metadata/attributes allow us to model external calls, load metadata allow us to model frontend knowledge of external memory