All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Luis R. Rodriguez" <mcgrof@kernel.org>
To: Jan Tulak <jtulak@redhat.com>
Cc: "Luis R. Rodriguez" <mcgrof@kernel.org>, linux-xfs@vger.kernel.org
Subject: Re: [PATCH 1/7] mkfs: Save raw user input field to the opts struct
Date: Sat, 29 Jul 2017 19:12:07 +0200	[thread overview]
Message-ID: <20170729171207.GN18884@wotan.suse.de> (raw)
In-Reply-To: <0c34504a-923a-20ac-9f03-6972e38bbfde@redhat.com>

On Fri, Jul 28, 2017 at 04:45:58PM +0200, Jan Tulak wrote:
> 
> 
> On 27/07/2017 18:27, Luis R. Rodriguez wrote:
> > On Thu, Jul 20, 2017 at 11:29:26AM +0200, Jan Tulak wrote:
> > > diff --git a/mkfs/xfs_mkfs.c b/mkfs/xfs_mkfs.c
> > > index a69190b9..4b030101 100644
> > > --- a/mkfs/xfs_mkfs.c
> > > +++ b/mkfs/xfs_mkfs.c
> > > @@ -107,6 +107,11 @@ unsigned int		sectorsize;
> > >    *     sets what is used with simple specifying the subopt (-d file).
> > >    *     A special SUBOPT_NEEDS_VAL can be used to require a user-given
> > >    *     value in any case.
> > > + *
> > > + *   raw_input INTERNAL
> > > + *     Filled raw string from the user, so we never lose that information e.g.
> > > + *     to print it back in case of an issue.
> > > + *
> > >    */
> > >   struct opt_params {
> > >   	const char	name;
> > > @@ -122,6 +127,7 @@ struct opt_params {
> > >   		long long	minval;
> > >   		long long	maxval;
> > >   		long long	defaultval;
> > > +		const char	*raw_input;
> > >   	}		subopt_params[MAX_SUBOPTS];
> > >   };
> > > @@ -729,6 +735,18 @@ struct opt_params mopts = {
> > >    */
> > >   #define WHACK_SIZE (128 * 1024)
> > > +static inline void
> > > +set_conf_raw(struct opt_params *opt, int subopt, const char *value)
> > > +{
> > > +	opt->subopt_params[subopt].raw_input = value;
> > > +}
> > There are no bounds check on the array here, I think set_conf_raw()
> > should return int and we would check the return value. It could
> > return -EINVAL if the subopt is invalid for instance.
> Good idea. The only issue is with the return code, that causes some issues
> when we are also returning values - I wanted the values to be turned into
> uint64. But do we need to return an error? I don't see what usecase there
> would be for it, other than detecting a bug. So an assert might be a better
> solution - then it can't happen that a wrong index is used and result not
> tested.

The setting of the value can be done by using an extra argument pointer. Then
if its set it be assigned. Otherwise it would be left alone. The return value
would return 0 on success, otherwise a standard return value indicating the
cause of the error.

I don't think we need the too small or too big, a simple range issue should
suffice and we have -ERANGE.

  Luis

  reply	other threads:[~2017-07-29 17:12 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-20  9:29 [PATCH 0/7] mkfs: save user input into opts table Jan Tulak
2017-07-20  9:29 ` [PATCH 1/7] mkfs: Save raw user input field to the opts struct Jan Tulak
2017-07-27 16:27   ` Luis R. Rodriguez
2017-07-28 14:45     ` Jan Tulak
2017-07-29 17:12       ` Luis R. Rodriguez [this message]
2017-08-02 14:30         ` Jan Tulak
2017-08-02 15:51           ` Jan Tulak
2017-08-02 19:41             ` Luis R. Rodriguez
2017-08-02 19:19           ` Luis R. Rodriguez
2017-08-03 13:07             ` Jan Tulak
2017-08-03 22:25               ` Luis R. Rodriguez
2017-08-04 13:50                 ` Jan Tulak
2017-08-07 17:26                   ` Luis R. Rodriguez
2017-08-07 17:36                     ` Jan Tulak
2017-07-20  9:29 ` [PATCH 2/7] mkfs: rename defaultval to flagval in opts Jan Tulak
2017-07-20  9:29 ` [PATCH 3/7] mkfs: remove intermediate getstr followed by getnum Jan Tulak
2017-07-20 15:54   ` Darrick J. Wong
2017-07-21  8:56     ` Jan Tulak
2017-07-26 20:49     ` Eric Sandeen
2017-07-27  7:50       ` Jan Tulak
2017-07-27 13:35         ` Eric Sandeen
2017-07-21 12:24   ` [PATCH 3/7 v2] " Jan Tulak
2017-07-26 23:23     ` Eric Sandeen
2017-07-20  9:29 ` [PATCH 4/7] mkfs: merge tables for opts parsing into one table Jan Tulak
2017-07-20  9:29 ` [PATCH 5/7] mkfs: move getnum within the file Jan Tulak
2017-07-26 23:27   ` Eric Sandeen
2017-07-20  9:29 ` [PATCH 6/7] mkfs: extend opt_params with a value field Jan Tulak
2017-07-27 16:18   ` Luis R. Rodriguez
2017-07-28 14:44     ` Jan Tulak
2017-07-29 17:02       ` Luis R. Rodriguez
2017-08-02 14:43         ` Jan Tulak
2017-08-02 16:57           ` Luis R. Rodriguez
2017-08-02 18:11             ` Jan Tulak
2017-08-02 19:48               ` Luis R. Rodriguez
2017-08-03 13:23                 ` Jan Tulak
2017-08-03 20:47                   ` Luis R. Rodriguez
2017-07-20  9:29 ` [PATCH 7/7] mkfs: save user input values into opts Jan Tulak
2017-07-26 23:53   ` Eric Sandeen
2017-07-27 14:21     ` Jan Tulak

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=20170729171207.GN18884@wotan.suse.de \
    --to=mcgrof@kernel.org \
    --cc=jtulak@redhat.com \
    --cc=linux-xfs@vger.kernel.org \
    /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.