search for: nbdkit_parse_s

...> -#include <inttypes.h> > +#include <stdlib.h> > #include <stdbool.h> > +#include <stdint.h> > +#include <inttypes.h> > +#include <limits.h> > #include <string.h> > #include <unistd.h> > > @@ -153,6 +156,180 @@ test_nbdkit_parse_size (void) > return pass; > } > > +static bool > +test_nbdkit_parse_ints (void) > +{ > + bool pass = true; > + > +#define PARSE(...) PARSE_(__VA_ARGS__) > +#define PARSE_(TYPE, FORMAT, TEST, RET, EXPECTED) \ > + do {...

...e your concern that 32-bit platforms are not tested as frequently. >>> +++ b/include/nbdkit-common.h >>> @@ -84,6 +84,28 @@ extern void nbdkit_vdebug (const char *msg, va_list args); >>> extern char *nbdkit_absolute_path (const char *path); >>> extern int64_t nbdkit_parse_size (const char *str); >>> extern int nbdkit_parse_bool (const char *str); >>> +extern int nbdkit_parse_int (const char *what, const char *str, >>> + int *r); >> >> Should we mark 'what' and 'str' as being non-null p...

...const char *str, uint32_t *r); > + int nbdkit_parse_int64_t (const char *what, > + const char *str, int64_t *r); > + int nbdkit_parse_uint64_t (const char *what, > + const char *str, uint64_t *r); > + int nbdkit_parse_ssize_t (const char *what, > + const char *str, ssize_t *r); > + int nbdkit_parse_size_t (const char *what, > + const char *str, size_t *r); [s]size_t is another one that can differ between 32- and 64-bit platforms; but I'm fine with ha...

...hould usually be a short descriptive string of what you are trying +to parse, eg: + + if (nbdkit_parse_int ("random seed", argv[1], &seed) == -1) + return -1; + +might print an error: + + random seed: could not parse number: "lalala" + =head2 Parsing sizes Use the C<nbdkit_parse_size> utility function to parse human-readable diff --git a/filters/cache/cache.c b/filters/cache/cache.c index 14a3c0a..faf6023 100644 --- a/filters/cache/cache.c +++ b/filters/cache/cache.c @@ -70,7 +70,7 @@ static pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER; unsigned blksize; enum cache_...

...const char *str, uint32_t *r); > > + int nbdkit_parse_int64_t (const char *what, > > + const char *str, int64_t *r); > > + int nbdkit_parse_uint64_t (const char *what, > > + const char *str, uint64_t *r); > > + int nbdkit_parse_ssize_t (const char *what, > > + const char *str, ssize_t *r); > > + int nbdkit_parse_size_t (const char *what, > > + const char *str, size_t *r); > > [s]size_t is another one that can differ between 32- and 64-bit > platf...

On 3/26/20 1:25 PM, Richard W.M. Jones wrote: > Note that this probably isn't testing anything because at least on > Linux the -undefined/-no-undefined flags appear to have no effect on > linking. > [skipping review of 5/9 for now, due to its size. I don't know how easy or hard it would be to split it into bisectable pieces: first introducing the library with just the

On 3/24/20 3:12 PM, Eric Blake wrote: >> (For non-mingw platforms) this breaks the source API promises rather >> seriously, so if I understand your proposal correctly I don't think >> this is a good idea.  It's possibly something we can consider for >> internal plugins, or for the V3 API. > > How does it break API to request that someone link against a

On 3/25/20 7:16 AM, Richard W.M. Jones wrote: > I think I understand now that libnbdkit.so won't break the ABI for > existing plugins. Does it require that plugins for newer nbdkit use > -lnbdkit (which would be a source API break) or would it still be > possible to compile without this? I guess as long as plugins do not > start using -no-undefined then it would still work, so

...2_t (const char *what, + const char *str, uint32_t *r); + int nbdkit_parse_int64_t (const char *what, + const char *str, int64_t *r); + int nbdkit_parse_uint64_t (const char *what, + const char *str, uint64_t *r); + int nbdkit_parse_ssize_t (const char *what, + const char *str, ssize_t *r); + int nbdkit_parse_size_t (const char *what, + const char *str, size_t *r); + +Parse string C<str> into an integer of various types. These functions +parse a decimal, hexadecimal (C&lt...

On Thu, Sep 19, 2019 at 11:32:47AM -0500, Eric Blake wrote: > > +static int > > +retry_config (nbdkit_next_config *next, void *nxdata, > > + const char *key, const char *value) > > +{ > > + int r; > > + > > + if (strcmp (key, "retries") == 0) { > > + if (sscanf (value, "%d", &retries) != 1 || retries < 0)

On Wed, Mar 25, 2020 at 07:46:37AM -0500, Eric Blake wrote: > On 3/25/20 7:16 AM, Richard W.M. Jones wrote: > >I think I understand now that libnbdkit.so won't break the ABI for > >existing plugins. Does it require that plugins for newer nbdkit use > >-lnbdkit (which would be a source API break) or would it still be > >possible to compile without this? I guess as

...*str, uint8_t *rp) server/public.c:nbdkit_parse_uint16_t (const char *what, const char *str, uint16_t *rp) server/public.c:nbdkit_parse_uint32_t (const char *what, const char *str, uint32_t *rp) server/public.c:nbdkit_parse_uint64_t (const char *what, const char *str, uint64_t *rp) server/public.c:nbdkit_parse_size (const char *str) server/public.c:nbdkit_parse_bool (const char *str) server/public.c:nbdkit_read_password (const char *value, char **password) server/public.c:nbdkit_nanosleep (unsigned sec, unsigned nsec) server/public.c:nbdkit_export_name (void) server/public.c:nbdkit_peer_name (struct sockad...

On 9/19/19 10:26 AM, Richard W.M. Jones wrote: > This filter can be used to transparently reopen/retry when a plugin > fails. The connection is closed and reopened which for most plugins > causes them to attempt to reconnect to their source. > > For example if doing a long or slow SSH copy: > > nbdkit -U - ssh host=remote /var/tmp/test.iso \ > --run 'qemu-img

This creates libnbdkit.so as discussed in the following thread: https://www.redhat.com/archives/libguestfs/2020-March/thread.html#00203 test-delay-shutdown.sh fails for unclear reasons. This series starts by reverting "tests: Don't strand hung nbdkit processes" which is because several other tests fail randomly unless I revert this patch. I didn't investigate this yet so it