[v17,01/14] util/cutils: Add Add qemu_strtold and qemu_strtold_finite
diff mbox series

Message ID 20191122074826.1373-2-tao3.xu@intel.com
State New
Headers show
Series
  • Build ACPI Heterogeneous Memory Attribute Table (HMAT)
Related show

Commit Message

Tao Xu Nov. 22, 2019, 7:48 a.m. UTC
Work like qemu_strtod() and qemu_strtold_finite, except store long
double.

Signed-off-by: Tao Xu <tao3.xu@intel.com>
---

No changes in v17.
---
 include/qemu/cutils.h |  3 +++
 util/cutils.c         | 48 ++++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 50 insertions(+), 1 deletion(-)

Comments

Tao Xu Nov. 25, 2019, 1:05 a.m. UTC | #1
Hi Markus,

Do you have any comments on this patch and 02/14 05/14 06/14.
Thank you!

On 11/22/2019 3:48 PM, Xu, Tao3 wrote:
> Work like qemu_strtod() and qemu_strtold_finite, except store long
> double.
> 
> Signed-off-by: Tao Xu <tao3.xu@intel.com>
> ---
> 
> No changes in v17.
> ---
>   include/qemu/cutils.h |  3 +++
>   util/cutils.c         | 48 ++++++++++++++++++++++++++++++++++++++++++-
>   2 files changed, 50 insertions(+), 1 deletion(-)
> 
> diff --git a/include/qemu/cutils.h b/include/qemu/cutils.h
> index b54c847e0f..48cf9bf776 100644
> --- a/include/qemu/cutils.h
> +++ b/include/qemu/cutils.h
> @@ -146,6 +146,9 @@ int qemu_strtou64(const char *nptr, const char **endptr, int base,
>                     uint64_t *result);
>   int qemu_strtod(const char *nptr, const char **endptr, double *result);
>   int qemu_strtod_finite(const char *nptr, const char **endptr, double *result);
> +int qemu_strtold(const char *nptr, const char **endptr, long double *result);
> +int qemu_strtold_finite(const char *nptr, const char **endptr,
> +                        long double *result);
>   
>   int parse_uint(const char *s, unsigned long long *value, char **endptr,
>                  int base);
> diff --git a/util/cutils.c b/util/cutils.c
> index fd591cadf0..5db3b2add5 100644
> --- a/util/cutils.c
> +++ b/util/cutils.c
> @@ -553,7 +553,7 @@ int qemu_strtou64(const char *nptr, const char **endptr, int base,
>   
>   /**
>    * Convert string @nptr to a double.
> -  *
> + *
>    * This is a wrapper around strtod() that is harder to misuse.
>    * Semantics of @nptr and @endptr match strtod() with differences
>    * noted below.
> @@ -616,6 +616,52 @@ int qemu_strtod_finite(const char *nptr, const char **endptr, double *result)
>       return ret;
>   }
>   
> +/*
> + * Convert string @nptr to a long double.
> + *
> + * Works like qemu_strtod(), except it stores long double.
> + */
> +int qemu_strtold(const char *nptr, const char **endptr, long double *result)
> +{
> +    char *ep;
> +
> +    if (!nptr) {
> +        if (endptr) {
> +            *endptr = nptr;
> +        }
> +        return -EINVAL;
> +    }
> +
> +    errno = 0;
> +    *result = strtold(nptr, &ep);
> +    return check_strtox_error(nptr, ep, endptr, errno);
> +}
> +
> +/*
> + * Convert string @nptr to a finite long double.
> + *
> + * Works like qemu_strtod_finite(), except it stores long double.
> + */
> +int qemu_strtold_finite(const char *nptr, const char **endptr,
> +                        long double *result)
> +{
> +    long double tmp;
> +    int ret;
> +
> +    ret = qemu_strtold(nptr, endptr, &tmp);
> +    if (!ret && !isfinite(tmp)) {
> +        if (endptr) {
> +            *endptr = nptr;
> +        }
> +        ret = -EINVAL;
> +    }
> +
> +    if (ret != -EINVAL) {
> +        *result = tmp;
> +    }
> +    return ret;
> +}
> +
>   /**
>    * Searches for the first occurrence of 'c' in 's', and returns a pointer
>    * to the trailing null byte if none was found.
>
Markus Armbruster Nov. 25, 2019, 6:45 a.m. UTC | #2
Tao Xu <tao3.xu@intel.com> writes:

> Work like qemu_strtod() and qemu_strtold_finite, except store long
> double.
>
> Signed-off-by: Tao Xu <tao3.xu@intel.com>
> ---
>
> No changes in v17.
> ---
>  include/qemu/cutils.h |  3 +++
>  util/cutils.c         | 48 ++++++++++++++++++++++++++++++++++++++++++-
>  2 files changed, 50 insertions(+), 1 deletion(-)
>
> diff --git a/include/qemu/cutils.h b/include/qemu/cutils.h
> index b54c847e0f..48cf9bf776 100644
> --- a/include/qemu/cutils.h
> +++ b/include/qemu/cutils.h
> @@ -146,6 +146,9 @@ int qemu_strtou64(const char *nptr, const char **endptr, int base,
>                    uint64_t *result);
>  int qemu_strtod(const char *nptr, const char **endptr, double *result);
>  int qemu_strtod_finite(const char *nptr, const char **endptr, double *result);
> +int qemu_strtold(const char *nptr, const char **endptr, long double *result);
> +int qemu_strtold_finite(const char *nptr, const char **endptr,
> +                        long double *result);
>  
>  int parse_uint(const char *s, unsigned long long *value, char **endptr,
>                 int base);
> diff --git a/util/cutils.c b/util/cutils.c
> index fd591cadf0..5db3b2add5 100644
> --- a/util/cutils.c
> +++ b/util/cutils.c
> @@ -553,7 +553,7 @@ int qemu_strtou64(const char *nptr, const char **endptr, int base,
>  
>  /**
>   * Convert string @nptr to a double.
> -  *
> + *
>   * This is a wrapper around strtod() that is harder to misuse.
>   * Semantics of @nptr and @endptr match strtod() with differences
>   * noted below.
> @@ -616,6 +616,52 @@ int qemu_strtod_finite(const char *nptr, const char **endptr, double *result)
>      return ret;
>  }
>  
> +/*
> + * Convert string @nptr to a long double.
> + *
> + * Works like qemu_strtod(), except it stores long double.

"except it stores long double" feels redundant.

In similar comments elsewhere in this file, we spell out the different
overflow behavior.  Let's do the same here, and replace the redundant
part by "except it stores +/-HUGE_VALL on overflow".

> + */
> +int qemu_strtold(const char *nptr, const char **endptr, long double *result)
> +{
> +    char *ep;
> +
> +    if (!nptr) {
> +        if (endptr) {
> +            *endptr = nptr;
> +        }
> +        return -EINVAL;
> +    }
> +
> +    errno = 0;
> +    *result = strtold(nptr, &ep);
> +    return check_strtox_error(nptr, ep, endptr, errno);
> +}
> +
> +/*
> + * Convert string @nptr to a finite long double.
> + *
> + * Works like qemu_strtod_finite(), except it stores long double.
> + */

Likewise.

> +int qemu_strtold_finite(const char *nptr, const char **endptr,
> +                        long double *result)
> +{
> +    long double tmp;
> +    int ret;
> +
> +    ret = qemu_strtold(nptr, endptr, &tmp);
> +    if (!ret && !isfinite(tmp)) {
> +        if (endptr) {
> +            *endptr = nptr;
> +        }
> +        ret = -EINVAL;
> +    }
> +
> +    if (ret != -EINVAL) {
> +        *result = tmp;
> +    }
> +    return ret;
> +}
> +
>  /**
>   * Searches for the first occurrence of 'c' in 's', and returns a pointer
>   * to the trailing null byte if none was found.

Preferably with the comments tweaked:
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Markus Armbruster Nov. 26, 2019, 1:54 p.m. UTC | #3
Tao Xu <tao3.xu@intel.com> writes:

> Hi Markus,
>
> Do you have any comments on this patch and 02/14 05/14 06/14.
> Thank you!

These provide a new QAPI built-in type 'time'.  It's like 'uint64' with
an implied nanoseconds unit, and additional convenience syntax in the
opts visitor and the keyval qobject input visitor.  Patterned after
'size'.

The only use of 'time' so far is member @latency of NumaOptions member
@hmap-lb.  Uses of that:

* QMP command set-numa-node

  The convenience syntax does not apply, as QMP uses the regular qobject
  input visitor, not the keyval one.

* CLI option -numa

  We first parse the option argument with QemuOpts, then convert it to
  NumaOptions with the opts visitor.

  The new built-in type 'time' gets used in -numa hmat-lb,...,latency=T

Questions / observations:

* The keyval qobject input visitor's support for 'time' appears to be
  unused for now.

* What's the anticipated range of values for -numa
  hmat-lb,...,latency=T?  I'm asking because I wonder whether we really
  need convenience syntax there.

* Sure you want fractions?

  Supporting fractions for byte counts (e.g.  1.5G) has been a mixed
  blessing, to put it charitably.

  Use of fractions that aren't representable as double is not advisable.
  For instance, 1.1G is 1181116006 bytes rounded from
  1181116006.4000001.  Why would anybody want that?

  Use of "nice" fractions is unproblematic, but the additional
  convenience is rather minor.  Is being able to write 1536M as 1.5G
  worth the trouble?  Meh.

  With "metric" rather than "binary" suffixes, fractions provide even
  less convenience: 1.5ms vs. 1500us.

  The implementation is limited to 53 bits of precision, which has been
  a source of confusion.  Even that has arguably taken far more patches
  than it's worth.  We're now talking about more patches to lift the
  restriction.  Meh.

  What exactly are we trying to achieve by supporting fractions?

* What about all the other time-valued things in the QAPI schema?

  There are many more, and some of them are also visible in CLI or HMP.
  By providing convenience syntax for just -numa hmat-lb,...,latency=T,
  we create inconsistency.

  To avoid it, we'd have to hunt down all the others.  But some of them
  aren't in nanoseconds.  Your new built-in type 'time' is only
  applicable to the ones in nanoseconds.  Do we need more built-in
  types?

This series is at v17.  I really, really want to tell you it's ready for
merging.  But as you see, I can't.

Maybe the convenience syntax is a good idea, maybe it's a bad idea.  But
it's definitely not a must-have idea.

If you want to pursue the idea, I recommend to split this series in two:
one part without the convenience, and a second part adding it.
Hopefully, we can then merge the first part without too much fuss.  The
second part will have to deal with the questions above.

You can also shelve the idea, i.e. do just the first part now.  It's
what I'd do.
Tao Xu Nov. 27, 2019, 4:37 a.m. UTC | #4
On 11/26/2019 9:54 PM, Markus Armbruster wrote:
> Tao Xu <tao3.xu@intel.com> writes:
> 
>> Hi Markus,
>>
>> Do you have any comments on this patch and 02/14 05/14 06/14.
>> Thank you!
> 
> These provide a new QAPI built-in type 'time'.  It's like 'uint64' with
> an implied nanoseconds unit, and additional convenience syntax in the
> opts visitor and the keyval qobject input visitor.  Patterned after
> 'size'.
> 
> The only use of 'time' so far is member @latency of NumaOptions member
> @hmap-lb.  Uses of that:
> 
> * QMP command set-numa-node
> 
>    The convenience syntax does not apply, as QMP uses the regular qobject
>    input visitor, not the keyval one.
> 
> * CLI option -numa
> 
>    We first parse the option argument with QemuOpts, then convert it to
>    NumaOptions with the opts visitor.
> 
>    The new built-in type 'time' gets used in -numa hmat-lb,...,latency=T
> 
> Questions / observations:
> 
> * The keyval qobject input visitor's support for 'time' appears to be
>    unused for now.
> 
> * What's the anticipated range of values for -numa
>    hmat-lb,...,latency=T?  I'm asking because I wonder whether we really
>    need convenience syntax there.
> 
> * Sure you want fractions?
> 
>    Supporting fractions for byte counts (e.g.  1.5G) has been a mixed
>    blessing, to put it charitably.
> 
>    Use of fractions that aren't representable as double is not advisable.
>    For instance, 1.1G is 1181116006 bytes rounded from
>    1181116006.4000001.  Why would anybody want that?
> 
>    Use of "nice" fractions is unproblematic, but the additional
>    convenience is rather minor.  Is being able to write 1536M as 1.5G
>    worth the trouble?  Meh.
> 
>    With "metric" rather than "binary" suffixes, fractions provide even
>    less convenience: 1.5ms vs. 1500us.
> 
>    The implementation is limited to 53 bits of precision, which has been
>    a source of confusion.  Even that has arguably taken far more patches
>    than it's worth.  We're now talking about more patches to lift the
>    restriction.  Meh.
> 
>    What exactly are we trying to achieve by supporting fractions?
> 
> * What about all the other time-valued things in the QAPI schema?
> 
>    There are many more, and some of them are also visible in CLI or HMP.
>    By providing convenience syntax for just -numa hmat-lb,...,latency=T,
>    we create inconsistency.
> 
>    To avoid it, we'd have to hunt down all the others.  But some of them
>    aren't in nanoseconds.  Your new built-in type 'time' is only
>    applicable to the ones in nanoseconds.  Do we need more built-in
>    types?
> 
> This series is at v17.  I really, really want to tell you it's ready for
> merging.  But as you see, I can't.
> 
> Maybe the convenience syntax is a good idea, maybe it's a bad idea.  But
> it's definitely not a must-have idea.
> 
> If you want to pursue the idea, I recommend to split this series in two:
> one part without the convenience, and a second part adding it.
> Hopefully, we can then merge the first part without too much fuss.  The
> second part will have to deal with the questions above.
> 
> You can also shelve the idea, i.e. do just the first part now.  It's
> what I'd do.
> 
Thank you for your suggestion and support! Considering ACPI HMAT can 
only store unsigned integer data, and for the memory latency nanoseconds 
is enough. So we can use integer for latency data. I am wondering if we 
can use this solution:

* Still add builtin type time, but use qemu_strtou64() to parse.
* Still refactor do_strtosz() to support suffixes list, but add a extra 
parameter to decide use qemu_strtou64() or qemu_strtod_finite(), so time 
use qemu_strtou64() and qemu_strtod_finite()
* Second part dealing with the questions.

Then the only influence on HMAT patch is we need add a comments to tell 
user to input integer.
Markus Armbruster Nov. 27, 2019, 6:44 a.m. UTC | #5
Tao Xu <tao3.xu@intel.com> writes:

> On 11/26/2019 9:54 PM, Markus Armbruster wrote:
>> Tao Xu <tao3.xu@intel.com> writes:
>>
>>> Hi Markus,
>>>
>>> Do you have any comments on this patch and 02/14 05/14 06/14.
>>> Thank you!
>>
>> These provide a new QAPI built-in type 'time'.  It's like 'uint64' with
>> an implied nanoseconds unit, and additional convenience syntax in the
>> opts visitor and the keyval qobject input visitor.  Patterned after
>> 'size'.
>>
>> The only use of 'time' so far is member @latency of NumaOptions member
>> @hmap-lb.  Uses of that:
>>
>> * QMP command set-numa-node
>>
>>    The convenience syntax does not apply, as QMP uses the regular qobject
>>    input visitor, not the keyval one.
>>
>> * CLI option -numa
>>
>>    We first parse the option argument with QemuOpts, then convert it to
>>    NumaOptions with the opts visitor.
>>
>>    The new built-in type 'time' gets used in -numa hmat-lb,...,latency=T
>>
>> Questions / observations:
>>
>> * The keyval qobject input visitor's support for 'time' appears to be
>>    unused for now.
>>
>> * What's the anticipated range of values for -numa
>>    hmat-lb,...,latency=T?  I'm asking because I wonder whether we really
>>    need convenience syntax there.
>>
>> * Sure you want fractions?
>>
>>    Supporting fractions for byte counts (e.g.  1.5G) has been a mixed
>>    blessing, to put it charitably.
>>
>>    Use of fractions that aren't representable as double is not advisable.
>>    For instance, 1.1G is 1181116006 bytes rounded from
>>    1181116006.4000001.  Why would anybody want that?
>>
>>    Use of "nice" fractions is unproblematic, but the additional
>>    convenience is rather minor.  Is being able to write 1536M as 1.5G
>>    worth the trouble?  Meh.
>>
>>    With "metric" rather than "binary" suffixes, fractions provide even
>>    less convenience: 1.5ms vs. 1500us.
>>
>>    The implementation is limited to 53 bits of precision, which has been
>>    a source of confusion.  Even that has arguably taken far more patches
>>    than it's worth.  We're now talking about more patches to lift the
>>    restriction.  Meh.
>>
>>    What exactly are we trying to achieve by supporting fractions?
>>
>> * What about all the other time-valued things in the QAPI schema?
>>
>>    There are many more, and some of them are also visible in CLI or HMP.
>>    By providing convenience syntax for just -numa hmat-lb,...,latency=T,
>>    we create inconsistency.
>>
>>    To avoid it, we'd have to hunt down all the others.  But some of them
>>    aren't in nanoseconds.  Your new built-in type 'time' is only
>>    applicable to the ones in nanoseconds.  Do we need more built-in
>>    types?
>>
>> This series is at v17.  I really, really want to tell you it's ready for
>> merging.  But as you see, I can't.
>>
>> Maybe the convenience syntax is a good idea, maybe it's a bad idea.  But
>> it's definitely not a must-have idea.
>>
>> If you want to pursue the idea, I recommend to split this series in two:
>> one part without the convenience, and a second part adding it.
>> Hopefully, we can then merge the first part without too much fuss.  The
>> second part will have to deal with the questions above.
>>
>> You can also shelve the idea, i.e. do just the first part now.  It's
>> what I'd do.
>>
> Thank you for your suggestion and support! Considering ACPI HMAT can
> only store unsigned integer data, and for the memory latency
> nanoseconds is enough. So we can use integer for latency data. I am
> wondering if we can use this solution:
>
> * Still add builtin type time, but use qemu_strtou64() to parse.
> * Still refactor do_strtosz() to support suffixes list, but add a
> extra parameter to decide use qemu_strtou64() or qemu_strtod_finite(),
> so time use qemu_strtou64() and qemu_strtod_finite()

We'd still have to grapple with "What about all the other time-valued
things in the QAPI schema?"

> * Second part dealing with the questions.
>
> Then the only influence on HMAT patch is we need add a comments to
> tell user to input integer.

Considerung we're already at v17, I recommend to keep the first part as
focused as possible.  Since plain integer types are good enough for time
values elsewhere in our external interfaces, they'll do for HMAT
latency, too.

Once the first part is accepted, you're free to tackle the wider problem
of providing convenience syntax for time values.  Fair warning: I
consider this a swamp.
Tao Xu Nov. 27, 2019, 7:22 a.m. UTC | #6
On 11/27/2019 2:44 PM, Markus Armbruster wrote:
> Tao Xu <tao3.xu@intel.com> writes:
> 
>> On 11/26/2019 9:54 PM, Markus Armbruster wrote:
>>> Tao Xu <tao3.xu@intel.com> writes:
>>>
>>>> Hi Markus,
>>>>
>>>> Do you have any comments on this patch and 02/14 05/14 06/14.
>>>> Thank you!
>>>
>>> These provide a new QAPI built-in type 'time'.  It's like 'uint64' with
>>> an implied nanoseconds unit, and additional convenience syntax in the
>>> opts visitor and the keyval qobject input visitor.  Patterned after
>>> 'size'.
>>>
>>> The only use of 'time' so far is member @latency of NumaOptions member
>>> @hmap-lb.  Uses of that:
>>>
>>> * QMP command set-numa-node
>>>
>>>     The convenience syntax does not apply, as QMP uses the regular qobject
>>>     input visitor, not the keyval one.
>>>
>>> * CLI option -numa
>>>
>>>     We first parse the option argument with QemuOpts, then convert it to
>>>     NumaOptions with the opts visitor.
>>>
>>>     The new built-in type 'time' gets used in -numa hmat-lb,...,latency=T
>>>
>>> Questions / observations:
>>>
>>> * The keyval qobject input visitor's support for 'time' appears to be
>>>     unused for now.
>>>
>>> * What's the anticipated range of values for -numa
>>>     hmat-lb,...,latency=T?  I'm asking because I wonder whether we really
>>>     need convenience syntax there.
>>>
>>> * Sure you want fractions?
>>>
>>>     Supporting fractions for byte counts (e.g.  1.5G) has been a mixed
>>>     blessing, to put it charitably.
>>>
>>>     Use of fractions that aren't representable as double is not advisable.
>>>     For instance, 1.1G is 1181116006 bytes rounded from
>>>     1181116006.4000001.  Why would anybody want that?
>>>
>>>     Use of "nice" fractions is unproblematic, but the additional
>>>     convenience is rather minor.  Is being able to write 1536M as 1.5G
>>>     worth the trouble?  Meh.
>>>
>>>     With "metric" rather than "binary" suffixes, fractions provide even
>>>     less convenience: 1.5ms vs. 1500us.
>>>
>>>     The implementation is limited to 53 bits of precision, which has been
>>>     a source of confusion.  Even that has arguably taken far more patches
>>>     than it's worth.  We're now talking about more patches to lift the
>>>     restriction.  Meh.
>>>
>>>     What exactly are we trying to achieve by supporting fractions?
>>>
>>> * What about all the other time-valued things in the QAPI schema?
>>>
>>>     There are many more, and some of them are also visible in CLI or HMP.
>>>     By providing convenience syntax for just -numa hmat-lb,...,latency=T,
>>>     we create inconsistency.
>>>
>>>     To avoid it, we'd have to hunt down all the others.  But some of them
>>>     aren't in nanoseconds.  Your new built-in type 'time' is only
>>>     applicable to the ones in nanoseconds.  Do we need more built-in
>>>     types?
>>>
>>> This series is at v17.  I really, really want to tell you it's ready for
>>> merging.  But as you see, I can't.
>>>
>>> Maybe the convenience syntax is a good idea, maybe it's a bad idea.  But
>>> it's definitely not a must-have idea.
>>>
>>> If you want to pursue the idea, I recommend to split this series in two:
>>> one part without the convenience, and a second part adding it.
>>> Hopefully, we can then merge the first part without too much fuss.  The
>>> second part will have to deal with the questions above.
>>>
>>> You can also shelve the idea, i.e. do just the first part now.  It's
>>> what I'd do.
>>>
>> Thank you for your suggestion and support! Considering ACPI HMAT can
>> only store unsigned integer data, and for the memory latency
>> nanoseconds is enough. So we can use integer for latency data. I am
>> wondering if we can use this solution:
>>
>> * Still add builtin type time, but use qemu_strtou64() to parse.
>> * Still refactor do_strtosz() to support suffixes list, but add a
>> extra parameter to decide use qemu_strtou64() or qemu_strtod_finite(),
>> so time use qemu_strtou64() and qemu_strtod_finite()
> 
> We'd still have to grapple with "What about all the other time-valued
> things in the QAPI schema?"
> 
>> * Second part dealing with the questions.
>>
>> Then the only influence on HMAT patch is we need add a comments to
>> tell user to input integer.
> 
> Considerung we're already at v17, I recommend to keep the first part as
> focused as possible.  Since plain integer types are good enough for time
> values elsewhere in our external interfaces, they'll do for HMAT
> latency, too.
> 
> Once the first part is accepted, you're free to tackle the wider problem
> of providing convenience syntax for time values.  Fair warning: I
> consider this a swamp.
> 

Thank you! I will use integer for HMAT latency and submit the first part 
in next version.

Patch
diff mbox series

diff --git a/include/qemu/cutils.h b/include/qemu/cutils.h
index b54c847e0f..48cf9bf776 100644
--- a/include/qemu/cutils.h
+++ b/include/qemu/cutils.h
@@ -146,6 +146,9 @@  int qemu_strtou64(const char *nptr, const char **endptr, int base,
                   uint64_t *result);
 int qemu_strtod(const char *nptr, const char **endptr, double *result);
 int qemu_strtod_finite(const char *nptr, const char **endptr, double *result);
+int qemu_strtold(const char *nptr, const char **endptr, long double *result);
+int qemu_strtold_finite(const char *nptr, const char **endptr,
+                        long double *result);
 
 int parse_uint(const char *s, unsigned long long *value, char **endptr,
                int base);
diff --git a/util/cutils.c b/util/cutils.c
index fd591cadf0..5db3b2add5 100644
--- a/util/cutils.c
+++ b/util/cutils.c
@@ -553,7 +553,7 @@  int qemu_strtou64(const char *nptr, const char **endptr, int base,
 
 /**
  * Convert string @nptr to a double.
-  *
+ *
  * This is a wrapper around strtod() that is harder to misuse.
  * Semantics of @nptr and @endptr match strtod() with differences
  * noted below.
@@ -616,6 +616,52 @@  int qemu_strtod_finite(const char *nptr, const char **endptr, double *result)
     return ret;
 }
 
+/*
+ * Convert string @nptr to a long double.
+ *
+ * Works like qemu_strtod(), except it stores long double.
+ */
+int qemu_strtold(const char *nptr, const char **endptr, long double *result)
+{
+    char *ep;
+
+    if (!nptr) {
+        if (endptr) {
+            *endptr = nptr;
+        }
+        return -EINVAL;
+    }
+
+    errno = 0;
+    *result = strtold(nptr, &ep);
+    return check_strtox_error(nptr, ep, endptr, errno);
+}
+
+/*
+ * Convert string @nptr to a finite long double.
+ *
+ * Works like qemu_strtod_finite(), except it stores long double.
+ */
+int qemu_strtold_finite(const char *nptr, const char **endptr,
+                        long double *result)
+{
+    long double tmp;
+    int ret;
+
+    ret = qemu_strtold(nptr, endptr, &tmp);
+    if (!ret && !isfinite(tmp)) {
+        if (endptr) {
+            *endptr = nptr;
+        }
+        ret = -EINVAL;
+    }
+
+    if (ret != -EINVAL) {
+        *result = tmp;
+    }
+    return ret;
+}
+
 /**
  * Searches for the first occurrence of 'c' in 's', and returns a pointer
  * to the trailing null byte if none was found.