From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38266) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zwb2f-0001Zl-BN for qemu-devel@nongnu.org; Wed, 11 Nov 2015 14:26:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zwb2S-0002Ev-U9 for qemu-devel@nongnu.org; Wed, 11 Nov 2015 14:26:49 -0500 References: <1443184788-18859-1-git-send-email-afaerber@suse.de> <1443184788-18859-2-git-send-email-afaerber@suse.de> <56055EED.2070503@redhat.com> From: =?UTF-8?Q?Andreas_F=c3=a4rber?= Message-ID: <56439662.3050406@suse.de> Date: Wed, 11 Nov 2015 20:26:26 +0100 MIME-Version: 1.0 In-Reply-To: <56055EED.2070503@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cLabw1EI0c9JaOLDXlcMFq0lqtpEJe5s5" Subject: Re: [Qemu-devel] [PATCH 1/7] string-input-visitor: Fix uint64 parsing List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake , qemu-devel@nongnu.org Cc: Markus Armbruster , qemu-stable@nongnu.org, Michael Roth , Bruce Rogers , Lin Ma , Paolo Bonzini This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cLabw1EI0c9JaOLDXlcMFq0lqtpEJe5s5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Am 25.09.2015 um 16:49 schrieb Eric Blake: > On 09/25/2015 06:39 AM, Andreas F=C3=A4rber wrote: >> All integers would get parsed by strtoll(), not handling the case of >> UINT64 properties with the most significient bit set. >> >> Implement a .type_uint64 visitor callback, reusing the existing >> parse_str() code through a new argument, using strtoull(). >> >> As a bug fix, ignore warnings about preference of qemu_strto[u]ll(). >> >> Cc: qemu-stable@nongnu.org >> Signed-off-by: Andreas F=C3=A4rber >> --- >> qapi/string-input-visitor.c | 57 ++++++++++++++++++++++++++++++++++++= +++++---- >> 1 file changed, 52 insertions(+), 5 deletions(-) >> >=20 >> @@ -50,7 +50,11 @@ static void parse_str(StringInputVisitor *siv, Erro= r **errp) >> =20 >> do { >> errno =3D 0; >> - start =3D strtoll(str, &endptr, 0); >> + if (u64) { >> + start =3D strtoull(str, &endptr, 0); >=20 > accepts the range [-ULLONG_MAX, ULLONG_MAX] (with 2s complement > wraparound). Do you really want -1 being a synonym for ULLONG_MAX, or d= o > you want to explicitly reject leading '-' when parsing unsigned > (arguments can be made for both behaviors; in fact, libvirt has two > separate wrappers for parsing uint64_t depending on which behavior is > wanted) >=20 >> + } else { >> + start =3D strtoll(str, &endptr, 0); >=20 > accepts the range [LLONG_MIN, LLONG_MAX] (that is, roughly half the > range of the unsigned version) No one has further commented on this, so I take it no further changes are required here for now. >> + } >> if (errno =3D=3D 0 && endptr > str) { >> if (*endptr =3D=3D '\0') { >> cur =3D g_malloc0(sizeof(*cur)); >> @@ -60,7 +64,7 @@ static void parse_str(StringInputVisitor *siv, Error= **errp) >> range_compa= re); >> cur =3D NULL; >> str =3D NULL; >> - } else if (*endptr =3D=3D '-') { >> + } else if (*endptr =3D=3D '-' && !u64) { >=20 > Why do you not want to handle ranges when using unsigned numbers? For some reason I must've read this as handling negative numbers, which we wouldn't have for unsigned numbers... However, since there is only one .start_list() callback, which passes !u64 to retain previous behavior, we would never actually run into this code path today. I've reverted my change and duplicated the strtoull() handling instead nonetheless. >> =20 >> +static void parse_type_uint64(Visitor *v, uint64_t *obj, const char *= name, >> + Error **errp) >> +{ >> + StringInputVisitor *siv =3D DO_UPCAST(StringInputVisitor, visitor= , v); >> + >> + if (!siv->string) { >> + error_setg(errp, QERR_INVALID_PARAMETER_TYPE, name ? name : "= null", >> + "integer"); >> + return; >> + } > ... >=20 > That's a lot of copy-and-paste. Can't you make parse_type_int64() and > parse_type_uint64() both call into a single helper method, that contain= s > the guts of the existing parse_type_int64() and adds a single parameter= > for the one place where the two functions differ on their call to > parse_str()? I don't see how. They have different signatures, and there's a lot of gotos that differ in the error message. I'm all for sharing code but it seems more work refactoring that code for reuse than duplication saved. If you have a concrete suggestion how to improve it, please share a diff or let's do that as follow-up. Regards, Andreas --=20 SUSE Linux GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Felix Imend=C3=B6rffer, Jane Smithard, Graham Norton; HRB 21284 (AG N= =C3=BCrnberg) --cLabw1EI0c9JaOLDXlcMFq0lqtpEJe5s5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJWQ5ZqAAoJEPou0S0+fgE/03wP/3a427bYdgYDAediIKXmg7LQ aUw8/4smyX84+PAgzqcFIDADtJBlfdZ47YUsyzhbyYWW30yr62LDlOiNWbwNZe8S 3nykJMKpGOldQpQkIOWam+2bSyHtxfXE2o/YC1kfECrAL07EYri1sk+8KJnlR287 Y5VAQEhlxrNeVgWtYJDY5q14r66sFYU6mofW8DCRi7NcRpZQl2yvP0hsAPUXVwiC OLadN55vTHFKqVFA9h31ody0qvP9u4U1oVg6pJVNKr5j5p05AtvGbS0aU0p3H9Zg rE5yVaBvcjJ+K9Dt0QHNybqCIpXTzv9Sf9WL5Lvl/XKx6VSIWKW+o96oKKoJgwu5 eFVfoMiorqSgJeIJxMxlBAlaFkXamZtOi/H4Foivsmb19YUCewZ4ogQIOzqpBIN/ DV1NXBY9DzdNZw8wy1pNwIGuRlgqkdvVpmX3dqEDItZ60NUg/8c8pfGSKfrtoldO UHUnw2G37IlIdreGZqr4XrUFZz87Qv5CjHWOqDYNxUEsl9Jx60Tut9aR3fwwC3qi vIBBLTzC4xicsA4lXvNsYMzSCOsQw1DL2O7/r+6WRQXydolNdlcm9vsacn2F//b/ LQFUeYwDKkvEtAPYISNh5BJq1L4yIndCBPRLsqwEkd9Gz0CiAhO1Fw33b33JOA9D 9m8flPpSc2wEoApuOnDc =bsam -----END PGP SIGNATURE----- --cLabw1EI0c9JaOLDXlcMFq0lqtpEJe5s5--