search for: offsetval

In the C part of the OCaml plugin we created a ‘bytes’ [byte array] and passed it to the OCaml pread method. The plugin is supposed to overwrite the array with the returned data. However if (eg. because of a bug) the plugin does not fill the array then whatever was in the OCaml or possibly even the C heap before the allocation is returned to the client, possibly resulting in a leak of sensitive

On Thu, Jan 26, 2017 at 08:58:34PM -0600, Eric Blake wrote: > diff --git a/plugins/ocaml/ocaml.c b/plugins/ocaml/ocaml.c > index e2b433e..5d7aeeb 100644 > --- a/plugins/ocaml/ocaml.c > +++ b/plugins/ocaml/ocaml.c > @@ -499,6 +499,17 @@ SET(pwrite) > SET(flush) > SET(trim) > > +/* We can't guarantee that errno is stable across language binding > + * glue code,

This was a bit harder than sh, but still a lot of copy-and-paste. Signed-off-by: Eric Blake <eblake@redhat.com> --- Note: I'm not sure how to actually test this beyond compilation. --- plugins/ocaml/ocaml.c | 51 ++++++++++++++++++++++++++++++++++++++++ plugins/ocaml/NBDKit.ml | 16 ++++++++++++- plugins/ocaml/NBDKit.mli | 5 ++++ 3 files changed, 71 insertions(+), 1 deletion(-)

This way it is possible to change where the matching start, instead of always assuming it is the beginning. --- common/mlpcre/PCRE.ml | 2 +- common/mlpcre/PCRE.mli | 5 ++++- common/mlpcre/pcre-c.c | 16 +++++++++++++--- common/mlpcre/pcre_tests.ml | 11 ++++++++--- 4 files changed, 26 insertions(+), 8 deletions(-) diff --git a/common/mlpcre/PCRE.ml b/common/mlpcre/PCRE.ml

This way it is possible to change where the matching start, instead of always assuming it is the beginning. --- common/mlpcre/PCRE.ml | 2 +- common/mlpcre/PCRE.mli | 5 ++++- common/mlpcre/pcre-c.c | 16 +++++++++++++--- common/mlpcre/pcre_tests.ml | 15 ++++++++++++--- 4 files changed, 30 insertions(+), 8 deletions(-) diff --git a/common/mlpcre/PCRE.ml b/common/mlpcre/PCRE.ml

But it's completely empty, no? const Type *llvm::ConvertibleToGEP(const Type *Ty, Value *OffsetVal, std::vector<Value*> &Indices, const TargetData &TD, BasicBlock::iterator *BI) { return 0; } in lib/Transforms/TransformInternals.cpp, how can this be? Naftali On Tue, 26...

Version 1 was here: https://www.redhat.com/archives/libguestfs/2019-April/msg00144.html Version 2 makes a couple of much larger changes: The OCaml patch changes the API of the pread method so it matches what other language bindings are already doing, ie. get the language plugin to return a newly allocated buffer, check it is long enough, copy out the data. The server patch implements a

On 01/27/2017 04:11 AM, Richard W.M. Jones wrote: > > Actually OCaml is a real compiled language, and the call from C to > OCaml code (via caml_callback_exn) is a short piece of asm which > preserves errno. Which shows my lack of familiarity with OCaml; but I'm guessing that also means that OCaml comes with easy ways to directly set errno so that it will be visible from C. >

On Tue, 26 Jul 2005, Naftali Schwartz wrote: > But it's completely empty, no? > > const Type *llvm::ConvertibleToGEP(const Type *Ty, Value *OffsetVal, > std::vector<Value*> &Indices, > const TargetData &TD, > BasicBlock::iterator *BI) { > return 0; > } > > in lib/Transforms/TransformInternals.cpp, how can this...

...unctionality is already present elsewhere or is simply not needed anymore? Naftali On Tue, 26 Jul 2005, Chris Lattner wrote: > On Tue, 26 Jul 2005, Naftali Schwartz wrote: >> But it's completely empty, no? >> >> const Type *llvm::ConvertibleToGEP(const Type *Ty, Value *OffsetVal, >> std::vector<Value*> &Indices, >> const TargetData &TD, >> BasicBlock::iterator *BI) { >> return 0; >> } >> >> in lib/Transforms/Transfo...

...he optimizer has already cleaned them up for you. -Chris > On Tue, 26 Jul 2005, Chris Lattner wrote: > >> On Tue, 26 Jul 2005, Naftali Schwartz wrote: >>> But it's completely empty, no? >>> >>> const Type *llvm::ConvertibleToGEP(const Type *Ty, Value *OffsetVal, >>> std::vector<Value*> &Indices, >>> const TargetData &TD, >>> BasicBlock::iterator *BI) { >>> return 0; >>> } >>> >>&g...

...for you. > > -Chris > > >> On Tue, 26 Jul 2005, Chris Lattner wrote: >> >>> On Tue, 26 Jul 2005, Naftali Schwartz wrote: >>>> But it's completely empty, no? >>>> >>>> const Type *llvm::ConvertibleToGEP(const Type *Ty, Value *OffsetVal, >>>> std::vector<Value*> &Indices, >>>> const TargetData &TD, >>>> BasicBlock::iterator *BI) { >>>> return 0; >>>> } >...

This series adds a new output mode for virt-v2v, called -o json. It produces local files, just like -o local, although the metadata produced is a JSON file with data that v2v collected in the conversion process. This can be useful for converting to unsupported destinations, still based on QEMU/KVM. In addition to a simple different metadata, it offers a way to relocate the disks, with

This bug was found by Eric Blake. In the .pread method we allocate a buffer in the server and pass it to the plugin. The plugin is supposed to fill it with data. The buffer was uninitialized so initially contained random heap data, but that's OK provided the plugin fully overwrote it with data. All correctly written plugins ought to do this, however there is the possibility of an

In the C part of the OCaml plugin we create a ‘bytes’ [byte array] and pass it to the OCaml pread method. The plugin should overwrite the array with the returned data. However if (eg. because of a bug) the plugin does not fill the array then whatever was in the OCaml or possibly even the C heap before the allocation is returned to the client, possibly resulting in a leak of sensitive data. We

It seems like general dependence analysis in LLVM should require that this function be, well, functional. Is it simply a placeholder waiting for someone to come and fill in the details? It also appears that some other things besides dependence analysis depend on it as well...anyone working on this? Naftali

On Tue, 26 Jul 2005, Naftali Schwartz wrote: > It seems like general dependence analysis in LLVM should require that this > function be, well, functional. Is it simply a placeholder waiting for > someone to come and fill in the details? It also appears that some other > things besides dependence analysis depend on it as well...anyone working on > this? I don't understand

This series adds a new output mode for virt-v2v, called -o json. It produces local files, just like -o local, although the metadata produced is a JSON file with data that v2v collected in the conversion process. This can be useful for converting to unsupported destinations, still based on QEMU/KVM. In addition to a simple different metadata, it offers a way to relocate the disks, with

This cleans up the existing code base with regards to implicit use of errno from language bindings, then rebases the previous work in python on top of that. I'm still playing with the perl bindings, but got further after reading 'perldoc perlembed'. Eric Blake (4): plugins: Don't use bogus errno from non-C plugins plugins: Add new nbdkit_set_error() utility function python:

Add a copy of the libvirt-ocaml library, currently available at: https://libvirt.org/git/?p=libvirt-ocaml.git;a=summary This is a snapshot at commit d3ed8dcf1b0a6a8a855ceecbe0bb97f21e6665e3, which has all the features we need (and that builds fine). It is expected to stay synchronized with upstream, until there is a new upstream release, and it will be widespread enough. --- .gitignore