similar to: [PATCH libguestfs] hivex: fail upon integer overflow

Hilko, forwarding this to the mailing list. Please post patches over there. Rich. ----- Forwarded message ----- Date: Wed, 21 Jul 2010 17:09:53 +0200 From: Hilko Bengen Subject: patch: non-ASCII characters in node names Hi Richard, I was a little bit surprised when a colleague claimed that key and value names in the registry could contain non-ASCII characters. I created keys and values

Signed-off-by: Alex Nelson <ajnelson at cs.ucsc.edu> --- generator/generator.ml | 6 ++++++ lib/hivex.c | 6 ++++++ xml/hivexml.c | 9 +++++++++ 3 files changed, 21 insertions(+), 0 deletions(-) diff --git a/generator/generator.ml b/generator/generator.ml index fc7b483..9e53f4e 100755 --- a/generator/generator.ml +++ b/generator/generator.ml @@ -159,6 +159,12

libxml2-utils.c local_string_to_utf8() function could easily be reused in other places. This commit extracts it with a new parameter to allow giving the encoding of the input string and publishes it in guestfs-utils.h as guestfs_int_string_to_utf8() --- common/utils/guestfs-utils.h | 11 +++++++ common/utils/libxml2-utils.c | 69 +------------------------------------------- common/utils/utils.c

Hi, libhivex seems to do a great job at parsing hives most of the time, but there are some issues with a few registry keys. These can be worked around in the application that uses libhivex, but I think it'd be better if libhivex handled these itself. 1. UTF16 string in REG_SZ that has garbage after the \0\0 There is code in hivex.c to handle this already but I think it has a typo: /*

The major and minor version were being reported in a debug message. This patch adds the version information to the ABI and reports with hivexml. Signed-off-by: Alex Nelson <ajnelson at cs.ucsc.edu> --- generator/generator.ml | 10 ++++++++++ lib/hivex.c | 32 +++++++++++++++++++++++++++----- xml/hivexml.c | 24 ++++++++++++++++++++++++ 3 files changed, 61

On Sat, Jun 27, 2015 at 2:46 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > In C, dunno, but in LLVM, it means they aren't readonly :) In that case, -functionattrs needs to be fixed: define void @infloop() { entry: br label %l l: br label %l } == opt -functionattrs ==> ; Function Attrs: readnone define void @infloop() #0 { entry: br label %l l:

We only use xmlParseURI to parse our own "homebrew" URIs, for example the ones used by guestfish --add or virt-v2v. Unfortunately xmlParseURI cannot handle URIs with spaces or other non-RFC-compliant characters so simple commands like these fail: $ guestfish -a 'ssh://example.com/virtual machine.img' guestfish: --add: could not parse URI 'ssh://example.com/virtual

The infrastructure for modified-time reporting has been essentially unused. These changes report the registry time by treating the time fields as Windows filetime fields stored in little-Endian (which means they can be treated as a single 64-bit little-Endian integer). This patch adds to the hivex ABI: * int64_t hivex_last_modified (hive_h *) * int64_t hivex_node_timestamp (hive_h *,

We only use xmlParseURI to parse our own "homebrew" URIs, for example the ones used by guestfish --add or virt-v2v. Unfortunately xmlParseURI cannot handle URIs with spaces or other non-RFC-compliant characters so simple commands like these fail: $ guestfish -a 'ssh://example.com/virtual machine.img' guestfish: --add: could not parse URI 'ssh://example.com/virtual

On Fri, Feb 09, 2018 at 01:52:52AM +0100, Hilko Bengen wrote: > It was brought to my attention that dumping a registry hive causes a > lot of time spent in disk I/O activity because iconv_open() and > iconv_close() are called for every key. Every iconv_open() call causes > /usr/lib/.../gconv/$ENCODING.so to be opened and mapped. > > The iconv_t handles are now cached in the

> You dropped some context... > A daemon program wouldn't be readonly. An infinite loop can be. Right. To prevent miscommunication, here is a quick analysis of a problematic (IMO) example: We start with ``` define void @infloop(i1 %c) { entry: br i1 %c, label %l, label %e l: br label %l e: ret void } define void @main_func() { entry: call void @infloop(i1 1) ret

----- Original Message ----- > From: "Nuno Lopes" <nunoplopes at sapo.pt> > To: "Sanjoy Das" <sanjoy at playingwithpointers.com>, "Jeremy Lakeman" <Jeremy.Lakeman at gmail.com>, nlewycky at google.com > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Sunday, June 28, 2015 6:08:52 AM > Subject: Re:

It was brought to my attention that dumping a registry hive causes a lot of time spent in disk I/O activity because iconv_open() and iconv_close() are called for every key. Every iconv_open() call causes /usr/lib/.../gconv/$ENCODING.so to be opened and mapped. The iconv_t handles are now cached in the hive_h struct; they are opened on-demand and re-used. On my ~10 year old Lenovo T60, I have

hivex has a function hivex_value_string. We were not calling it under the mistaken belief that because hivex implements this using iconv, the function wouldn't work inside the daemon. Instead we reimplemented the functionality in the library. This commit deprecates hivex_value_utf8 and removes the library side code. It replaces it with a plain wrapper around hivex_value_string. Thanks:

The infrastructure for modified-time reporting has been essentially unused. These changes report the registry time by treating the time fields as Windows filetime fields stored in little-Endian (which means they can be treated as a single 64-bit little-Endian integer). This patch adds the node_mtime function to the visitor API. Signed-off-by: Alex Nelson <ajnelson at cs.ucsc.edu> ---

--- lib/hivex-internal.h | 8 +++++--- lib/utf16.c | 11 +++++++---- 2 files changed, 12 insertions(+), 7 deletions(-) diff --git a/lib/hivex-internal.h b/lib/hivex-internal.h index 4135f58..64fd49a 100644 --- a/lib/hivex-internal.h +++ b/lib/hivex-internal.h @@ -268,11 +268,13 @@ extern size_t * _hivex_return_offset_list (offset_list *list); extern void _hivex_print_offset_list

It was brought to my attention that dumping a registry hive causes a lot of time spent in disk I/O activity because iconv_open() and iconv_close() are called for every key. Every iconv_open() call causes /usr/lib/.../gconv/$ENCODING.so to be opened and mapped. The iconv_t handles are now cached in the hive_h struct; they are opened on-demand and re-used. On my ~10 year old Lenovo T60, I have

Btw, here is another interesting paper about post-dominators and control dependence: https://pdfs.semanticscholar.org/cbb2/9a0e4895025bd9df24f9263217df12f1ed1e.pdf I think a great outcome of your internship would be some precise documentation regarding the guarantees the LLVM dominators give -- possibly also considering classic and weak control dependence and the difference between

Hello all, Source and binaries for LLVM 3.6.0-rc4 are available at http://llvm.org/pre-releases/3.6.0/ There were only a few new patches since rc3: an infloop fix (r229421) a few X86 fixes (r229555, r229561 and r229564), a GCC 5 bootstrap fix (PR22625) and performance regression fix for PR22589. If this one looks good, it will be promoted to 'final' sometime next week. Thanks again to

This line was accidentally removed in 77fe74fc, causing bug #1145056 (Bugzilla) to resurface. --- lib/utf16.c | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/utf16.c b/lib/utf16.c index e099548..67fa996 100644 --- a/lib/utf16.c +++ b/lib/utf16.c @@ -58,6 +58,7 @@ _hivex_recode (hive_h *h, recode_type t, /* Reset errno here because we don't want to accidentally * return