Date: Thu, 18 Mar 2021 12:23:33 -0400 From: Allan Jude <allanjude@freebsd.org> To: freebsd-hackers@freebsd.org Subject: Re: UCL library bug Message-ID: <5f755463-7285-4e45-106c-dc238d5e0d15@freebsd.org> In-Reply-To: <2b96997e-40fb-f337-d94b-60c4f1a2f31e@grosbein.net> References: <CAOxbktb3cQWHUgBD1yB==pMg8p2JkDAPx0-HQ6RZvQ-v0LRY1Q@mail.gmail.com> <2b96997e-40fb-f337-d94b-60c4f1a2f31e@grosbein.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3/16/2021 6:11 AM, Eugene Grosbein wrote: > 16.03.2021 16:03, IonuČ› Mihalache wrote: > >> Hello, >> >> I am using the ucl library to write in a file 64bit values. The data type >> is uint64_t or int64_t; on write I use %lu or %ld regarding the type and >> everything works, on read on the other hand something weird seems to happen: >> >> I read using %ld only and for small value it works, for values like >> 18,374,686,479,671,672,848 >> the ucl type type is recognized as UCL_STRING instead of UCL_INT and I >> don't know why this is happening. Is there a bug in the library? > > Does it help if you use %lld instead? Or maybe %jd ? > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > There is an ENUM called ucl_string_flags that controls how a string is parsed, it includes options for parsing it as a boolean, as int or double, or as a timestamp. We could extend this, and add UCL_STRING_PARSE_UINT or something, then change ucl_maybe_parse_number() to respect that flag, and then use strtoumax() instead of strtoimax(). I think the reason it uses strtoimax() by default, is that JSON only supports signed integers. -- Allan Jude
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5f755463-7285-4e45-106c-dc238d5e0d15>