Skip site navigation (1)Skip section navigation (2)
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>