public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: "Radim Krčmář" <rkrcmar@redhat.com>
To: Andrew Jones <drjones@redhat.com>
Cc: kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
	Thomas Huth <thuth@redhat.com>,
	Laurent Vivier <lvivier@redhat.com>
Subject: Re: [kvm-unit-tests PATCH 2/2] lib/util,arm,powerpc: replace parse_keyval with better helpers
Date: Thu, 12 May 2016 15:00:51 +0200	[thread overview]
Message-ID: <20160512130050.GB5864@potion> (raw)
In-Reply-To: <20160512071908.537ltvwkiiekqvri@hawk.localdomain>

2016-05-12 09:19+0200, Andrew Jones:
> On Wed, May 11, 2016 at 10:55:14PM +0200, Radim Krčmář wrote:
>> A common pattern was to scan through all argv strings to find key or
>> key=val.  parse_keyval used to return val as long, but another function
>> needed to check the key.  New functions do both at once.
>> 
>> parse_keyval was replaced with different parse_keyval, so callers needed
>> to be updated.  While at it, I changed the meaning of arguments to
>> powerpc/rtas.c to make the code simpler.  And removing aborts is a
>> subtle preparation for a patch that reports SKIP when no tests were run
>> and they weren't necessary even now.
>> 
>> Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
>> ---
>> diff --git a/lib/util.c b/lib/util.c
>> @@ -4,15 +4,43 @@
>> +long atol_keyval(int argc, char **argv, char *key)
>> +{
>> +	long val;
>> +	bool is_keyval = parse_keyval(argc, argv, key, &val);
>> +
>> +	return is_keyval ? val : 0;
> 
> Not sure how this one would be useful, and I don't see any uses
> for it below. It may be difficult to use due to its ambiguous
> results,  as zero could be the value, or the result because the
> key wasn't found, or because the key was found, but was a key
> with no '='.

I don't like parse_keyval, because it forces you to pass 'long' even if
you want a boolean out of it.  I wanted a function that doesn't impose a
type ... it's not needed, I'll get rid of it.

>> +bool find_key(int argc, char **argv, char *key) {
> 
> Mr. {, please come down.

How dare you colloquially address the King of Curly Brackets.

>> +	return find_keyval(argc, argv, key) == key;
>> +}
>> +
>> +char * find_keyval(int argc, char **argv, char *key)
> 
> I prefer the '*' by the name.

Ok, seems like it is the normal way.  I consider the name of returned
variable to be "" (empty string), so the pointer is by it. ;)

>> +{
>> +	int i;
>> +	size_t keylen = strlen(key);
>> +
>> +	for (i = 1; i < argc; i++) {
>
> We should start i at 0, because we shouldn't assume the user will
> always pass in main's &argv[0]. Above arm/setup.c actually uses
> &argv[1]; so does arm's setup test work? Anyway, it shouldn't matter
> if we always look at the program name while searching for the key,
> because, for example, x86/msr.flat would be a strange key name :-)

Sure, I'll rename argc and argv (to nr_strings and strings?), so it's
not confusing.

>> diff --git a/lib/util.h b/lib/util.h
>> @@ -8,16 +8,24 @@
>>   * This work is licensed under the terms of the GNU LGPL, version 2.
>>   */
>>  
>> -/*
>> - * parse_keyval extracts the integer from a string formatted as
>> - * string=integer. This is useful for passing expected values to
>> - * the unit test on the command line, i.e. it helps parse QEMU
>> - * command lines that include something like -append var1=1 var2=2
>> - * @s is the input string, likely a command line parameter, and
>> - * @val is a pointer to where the integer will be stored.
>> - *
>> - * Returns the offset of the '=', or -1 if no keyval pair is found.
>> +/* @argc and @argv are standard arguments to C main.  */
> 
> I agree the only use for a parsing function in kvm-unit-tests is
> main()'s inputs, but we shouldn't expect/require them to be unmodified
> prior to making parse_keyval calls.

I didn't mean they have to be unmodified, just that argc is the length
of argv array and the first element is ignored, because it's not an
argument ...

>> +
>> +/* parse_keyval returns true if @argv[i] has @key=val format and parse @val;
>> + * returns false otherwise.
>>   */
> 
> How about this instead
> 
> /*
>  * parse_keyval searches @argv members for strings of the form @key=val
>  * Returns
>  *  true when a @key=val string is found; val is parsed and stored in @val.
>  *  false otherwise
>  */
> 
>> -extern int parse_keyval(char *s, long *val);
>> +bool parse_keyval(int argc, char **argv, char *key, long *val);
>> +
>> +/* atol_keyval returns parsed val if @argv[i] has @key=val format; returns 0
> 
> same comment rewrite suggestion as above
> 
>> + * otherwise.
>> + */
>> +long atol_keyval(int argc, char **argv, char *key);
>> +
>> +/* find_key decides whether @key is equal @argv[i]. */
> 
> s/equal/equal to/, but I'd rewrite this one too :-)
> 
> /*
>  * find_key searches @argv members for the string @key
>  * Returns true when found, false otherwise.
>  */

I'll add explanation of argc and use them.

>> +bool find_key(int argc, char **argv, char *key);
>> +
>> +/* find_keyval returns key if @key is equal to @argv[i]; returns pointer to val
>> + * if @argv[i] has @key=val format; returns NULL otherwise.
>> + */
> 
> Another rewrite suggestion. Please list the return possibilities
> Returns
>  - @key when ...
>  - A pointer to the start of val when ...
>  - NULL otherwise
> 
> or something like that

Sure, thanks.

      parent reply	other threads:[~2016-05-12 13:00 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-11 20:55 [kvm-unit-tests PATCH 0/2] lib,arm,powerpc: change command line parsing Radim Krčmář
2016-05-11 20:55 ` [kvm-unit-tests PATCH 1/2] lib/string: add strncmp Radim Krčmář
2016-05-12  7:02   ` Laurent Vivier
2016-05-11 20:55 ` [kvm-unit-tests PATCH 2/2] lib/util,arm,powerpc: replace parse_keyval with better helpers Radim Krčmář
2016-05-12  7:19   ` Andrew Jones
2016-05-12  8:05     ` Andrew Jones
2016-05-12  8:09       ` Laurent Vivier
2016-05-12 13:22         ` Radim Krčmář
2016-05-12 13:27           ` Thomas Huth
2016-05-12 13:17       ` Radim Krčmář
2016-05-12 13:00     ` Radim Krčmář [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160512130050.GB5864@potion \
    --to=rkrcmar@redhat.com \
    --cc=drjones@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=lvivier@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=thuth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox