All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.