search for: nbdkit_parse_ssize_t

...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<&quot...

...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 having t...

...>>> * after reporting the error. >>> */ >> >> Hmm, seeing this comment, do we really need raw [s]size_t parsing, or >> can we get away with scaled parsing anywhere that sizes are intended? >> But the code looks correct if you want to keep it. > > nbdkit_parse_ssize_t is not used. nbdkit_parse_size_t is used for a > single case, ‘xz-max-depth’ which is genuinely an array length, so > size_t is (albeit marginally) useful here. It's also an array length where a misconfigured input can cause the filter to be non-functional; see commit fd2deeb1 where I a...

...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;...