Let's use the new function. "NaN" and "inf" are now properly rejected.

Signed-off-by: David Hildenbrand <david@redhat.com>
---
 qapi/string-input-visitor.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/qapi/string-input-visitor.c b/qapi/string-input-visitor.c
index b3fdd0827d..b89c6c4e06 100644
--- a/qapi/string-input-visitor.c
+++ b/qapi/string-input-visitor.c
@@ -20,6 +20,7 @@
 #include "qemu/option.h"
 #include "qemu/queue.h"
 #include "qemu/range.h"
+#include "qemu/cutils.h"
 
 
 struct StringInputVisitor
@@ -313,12 +314,9 @@ static void parse_type_number(Visitor *v, const char *name, double *obj,
                               Error **errp)
 {
     StringInputVisitor *siv = to_siv(v);
-    char *endp = (char *) siv->string;
     double val;
 
-    errno = 0;
-    val = strtod(siv->string, &endp);
-    if (errno || endp == siv->string || *endp) {
+    if (qemu_strtod_finite(siv->string, NULL, &val)) {
         error_setg(errp, QERR_INVALID_PARAMETER_TYPE, name ? name : "null",
                    "number");
         return;
-- 
2.17.2

On 11/15/18 8:04 AM, David Hildenbrand wrote:
> Let's use the new function. "NaN" and "inf" are now properly rejected.
> 
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
>   qapi/string-input-visitor.c | 6 ++----
>   1 file changed, 2 insertions(+), 4 deletions(-)

Reviewed-by: Eric Blake <eblake@redhat.com>

Should there be any added test coverage in this patch, or is it later in 
the series?

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

On 15.11.18 15:37, Eric Blake wrote:
> On 11/15/18 8:04 AM, David Hildenbrand wrote:
>> Let's use the new function. "NaN" and "inf" are now properly rejected.
>>
>> Signed-off-by: David Hildenbrand <david@redhat.com>
>> ---
>>   qapi/string-input-visitor.c | 6 ++----
>>   1 file changed, 2 insertions(+), 4 deletions(-)
> 
> Reviewed-by: Eric Blake <eblake@redhat.com>
> 
> Should there be any added test coverage in this patch, or is it later in 
> the series?

Nope not yet, but can add.


-- 

Thanks,

David / dhildenb

David Hildenbrand <david@redhat.com> writes:

> Let's use the new function. "NaN" and "inf" are now properly rejected.
>
> Signed-off-by: David Hildenbrand <david@redhat.com>

Whether this is a bug fix or just a change is debatable.  But the commit
message's title should highlight the change.  Perhaps you want to steal
from the one I suggested for the previous patch.

We need to assess backward compatibility impact.  I can do that.

> ---
>  qapi/string-input-visitor.c | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/qapi/string-input-visitor.c b/qapi/string-input-visitor.c
> index b3fdd0827d..b89c6c4e06 100644
> --- a/qapi/string-input-visitor.c
> +++ b/qapi/string-input-visitor.c
> @@ -20,6 +20,7 @@
>  #include "qemu/option.h"
>  #include "qemu/queue.h"
>  #include "qemu/range.h"
> +#include "qemu/cutils.h"
>  
>  
>  struct StringInputVisitor
> @@ -313,12 +314,9 @@ static void parse_type_number(Visitor *v, const char *name, double *obj,
>                                Error **errp)
>  {
>      StringInputVisitor *siv = to_siv(v);
> -    char *endp = (char *) siv->string;
>      double val;
>  
> -    errno = 0;
> -    val = strtod(siv->string, &endp);
> -    if (errno || endp == siv->string || *endp) {
> +    if (qemu_strtod_finite(siv->string, NULL, &val)) {
>          error_setg(errp, QERR_INVALID_PARAMETER_TYPE, name ? name : "null",
>                     "number");
>          return;

On 15.11.18 17:48, Markus Armbruster wrote:
> David Hildenbrand <david@redhat.com> writes:
> 
>> Let's use the new function. "NaN" and "inf" are now properly rejected.
>>
>> Signed-off-by: David Hildenbrand <david@redhat.com>
> 
> Whether this is a bug fix or just a change is debatable.  But the commit
> message's title should highlight the change.  Perhaps you want to steal
> from the one I suggested for the previous patch.

Yes, will copy+modify that one.

> 
> We need to assess backward compatibility impact.  I can do that.
Thanks! I assume this shouldn't be an issue.

-- 

Thanks,

David / dhildenb