search for: uint64_max

...ed value, unless the original (nonnegated) value would overflow." Later validation doesn't catch the situation when parsed value is within the valid range but original string passed to a function represented negative number. Thus nbdkit_parse_size() incorrectly parsed values in a range [-UINT64_MAX; INT64_MIN -1] translating them into an unsigned range of a valid values: [1; INT64_MAX]. In this patch: 1. strtoll() is used instead of strtoumax() to reflect the nature of the 'size' which cannot be negative and isn't expected to exceed INT64_MAX. 2. Error reporting separates cases...

...nonnegated) value would overflow." Later validation doesn't catch the situation when parsed value appeared within the valid range (due to negation) but original string passed to a function literally represented negative number. Thus nbdkit_parse_size() treats negative values in a range [-UINT64_MAX; INT64_MIN - 1] as positive values in a range [1; INT64_MAX] due to negation performed by strtoumax(). In this patch: 1. strtoimax() is used instead of strtoumax() to reflect the nature of the 'size' which cannot be negative and is not expected to exceed INT64_MAX. 2. Error reporting sep...

2008/11/24 David Flynn <davidf+nntp at woaf.net>: > On a slightly unrelated note, i keep hitting the following error in > liboggz when using the oggz tools on an ogg dirac stream: > > /home/davidf/project/liboggz/src/liboggz/oggz.c:202: oggz_close: > Assertion `oggz_dlist_is_empty(oggz->packet_buffer)' failed. > > I'll supply an example file tomorrow if that

This is the first part of a pair of patch series which aim to let us use nbdkit_parse_size (or rather, an equivalent common function) in nbdcopy, so we can write: nbdcopy --request-size=32M ... We can't do that now which was annoying me earlier in the week. This commit creates a new function called human_size_parse which is basically nbdkit_parse_size, and turns nbdkit_parse_size into a

...// FIXME: Implement error handling that doesn't kill the host program! if (!Addr) { report_fatal_error("Program used external function '" + Name + "' which could not be resolved!"); } // If Resolver returned UINT64_MAX, the client wants to handle this symbol // manually and we shouldn't resolve its relocations. if (Addr != UINT64_MAX) { DEBUG(dbgs() << "Resolving relocations Name: " << Name << "\t" << format("0x%lx", Addr) &l...

See companion patch: Subject: [PATCH nbdkit] server: Move size parsing code (nbdkit_parse_size) to common/include This is the second part of the patch. It adds the new human_size_parse function to libnbd and then uses it for parsing --queue-size, --request-size and --sparse. The main complication here is that there was already a common/utils/human-size.h header which ends up (eventually)

...xit (EXIT_FAILURE); } - end = extents[i].offset + extents[i].length; + end = extents.ptr[i].offset + extents.ptr[i].length; } /* If there's a gap at the beginning, insert a hole|zero extent. */ - if (nr_extents == 0 || extents[0].offset > 0) { - end = nr_extents == 0 ? UINT64_MAX : extents[0].offset; - insert_extent (0, (struct extent){.offset = 0, .length = end, - .type = HOLE}); + if (extents.size == 0 || extents.ptr[0].offset > 0) { + end = extents.size == 0 ? UINT64_MAX : extents.ptr[0].offset; + if (extent_list_insert (...

...ill the host program! > > if (!Addr) { > > report_fatal_error("Program used external function '" + Name + > > "' which could not be resolved!"); > > } > > > > // If Resolver returned UINT64_MAX, the client wants to handle this symbol > > // manually and we shouldn't resolve its relocations. > > if (Addr != UINT64_MAX) { > > DEBUG(dbgs() << "Resolving relocations Name: " << Name << "\t" > > &lt...

...// FIXME: Implement error handling that doesn't kill the host program! if (!Addr) { report_fatal_error("Program used external function '" + Name + "' which could not be resolved!"); } // If Resolver returned UINT64_MAX, the client wants to handle this symbol // manually and we shouldn't resolve its relocations. if (Addr != UINT64_MAX) { DEBUG(dbgs() << "Resolving relocations Name: " << Name << "\t" << format("0x%lx", Addr) &l...

...// FIXME: Implement error handling that doesn't kill the host program! if (!Addr) { report_fatal_error("Program used external function '" + Name + "' which could not be resolved!"); } // If Resolver returned UINT64_MAX, the client wants to handle this symbol // manually and we shouldn't resolve its relocations. if (Addr != UINT64_MAX) { DEBUG(dbgs() << "Resolving relocations Name: " << Name << "\t" << format("0x%lx", Addr) &l...

--- plugins/vddk/vddk.c | 41 +++++++++++++++++++++++++---------------- TODO | 1 - 2 files changed, 25 insertions(+), 17 deletions(-) diff --git a/plugins/vddk/vddk.c b/plugins/vddk/vddk.c index 87c0d146..d1a3015f 100644 --- a/plugins/vddk/vddk.c +++ b/plugins/vddk/vddk.c @@ -51,6 +51,7 @@ #include "isaligned.h" #include "minmax.h" #include

...<djm at mindrot.org> 2007-05-17 20:25:22 --- Created an attachment (id=1287) --> (http://bugzilla.mindrot.org/attachment.cgi?id=1287) make sftp use off_t Perhaps it would be better for sftp to use an off_t here? I don't think the OS would support files with OFF_T_MAX < size <= UINT64_MAX anyway -- Configure bugmail: http://bugzilla.mindrot.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

...ill the host program! > > if (!Addr) { > > report_fatal_error("Program used external function '" + Name + > > "' which could not be resolved!"); > > } > > > > // If Resolver returned UINT64_MAX, the client wants to handle this symbol > > // manually and we shouldn't resolve its relocations. > > if (Addr != UINT64_MAX) { > > DEBUG(dbgs() << "Resolving relocations Name: " << Name << "\t" > > &lt...

...nfused. It chooses a scaling factor of 1 / Min, which almost always turns up to be 1. This was causing me grief in the double nested loop case because the inner loop had a freq of about 6e20 while the outer blocks had a frequency of 2e19. With a scaling factor of 1, we were saturating everything to UINT64_MAX. I changed it so it uses a scaling factor that puts the frequencies in [1, UINT32_MAX], but only if the Max frequency is outside that range. This is causing two failures in the testsuite, which seem to be caused by RA spilling differently. I believe that in CodeGen/X86/lsr-i386.ll we are hoisting...

...!= ULONG_MAX - if (r > UINT32_MAX) - errno = ERANGE; -#endif - PARSE_COMMON_TAIL; -} - -int -nbdkit_parse_uint64_t (const char *what, const char *str, uint64_t *rp) -{ - unsigned long long r; - char *end; - - PARSE_ERROR_IF_NEGATIVE; - errno = 0; - r = strtoull (str, &end, 0); -#if UINT64_MAX != ULONGLONG_MAX - if (r > UINT64_MAX) - errno = ERANGE; -#endif - PARSE_COMMON_TAIL; -} - -/* Parse a string as a size with possible scaling suffix, or return -1 - * after reporting the error. - */ -int64_t -nbdkit_parse_size (const char *str) -{ - int64_t size; - char *end; - uint64_t...

...ode that tries to calculate granulepos > when it is not present on the page, which is actually unecessary for > this mapping -- so I expect it will be straightforward to fix. > Of course the file will be necessary to debug it :-) Solved. The ogg file in question had an EOS page with gp = UINT64_MAX and liboggz stashes all packets away in the packet_buffer until a gp is found. Hacking the muxer i was using to set the eos page to have a timestamp of 0 solves it. I'll now need to make it sample-and-hold for the eos page. I do find that a bit ugly -- using a magic value in a timestamp to i...

...++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/usr/kinit/ipconfig/main.c b/usr/kinit/ipconfig/main.c index 476384a..7be2a1f 100644 --- a/usr/kinit/ipconfig/main.c +++ b/usr/kinit/ipconfig/main.c @@ -147,8 +147,9 @@ static void dump_device_config(struct netdev *dev) * sizeof(UINT64_MAX)==21 */ char buf21[21]; + const char path[] = "/run/"; - snprintf(fn, sizeof(fn), "/tmp/net-%s.conf", dev->name); + snprintf(fn, sizeof(fn), "%snet-%s.conf", path, dev->name); f = fopen(fn, "w"); if (f) { write_option(f, "DEVICE"...

...(IC->getPredicate()) { + case ICmpInst::ICMP_EQ: + case ICmpInst::ICMP_NE: + case ICmpInst::ICMP_UGT: + case ICmpInst::ICMP_UGE: + case ICmpInst::ICMP_ULE: + case ICmpInst::ICMP_SGT: + case ICmpInst::ICMP_SGE: + case ICmpInst::ICMP_SLE: + // XXX: check for wrapping + if (con_val == UINT64_MAX) + return nullptr; + return emitStrNLen(Src, ConstantInt::get(SizeType, con_val + 1), + B, DL, TLI); + case ICmpInst::ICMP_ULT: + case ICmpInst::ICMP_SLT: + return emitStrNLen(Src, Con, + B, DL, TLI); + default: + return nullptr; + } + return nullptr; }

On Thu, May 28, 2020 at 6:03 AM Alexey Lapshin <alapshin at accesssoftek.com> wrote: > Hi David, > > > >So there have been several recent discussions about the issues around > > >DWARF-agnostic linking and gc-sections, linkonce function definitions > being > > >dropped, etc - and just how much DWARF-awareness would be suitable > > >in a linker to

Hi Lang, Can you please let me know you think it would be right to modify RuntimeDyldImpl::resolveExternalSymbols to allow resolvers to return 0 addresses? Something like this would be ideal for me: void RuntimeDyldImpl::resolveExternalSymbols() { while (!ExternalSymbolRelocations.empty()) { StringMap<RelocationList>::iterator i = ExternalSymbolRelocations.begin(); StringRef