All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: "Richard W.M. Jones" <rjones@redhat.com>,
	Max Reitz <mreitz@redhat.com>,
	qemu-block@nongnu.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v2] qemu-io: Reinitialize optind to 1 (not 0) before parsing inner command.
Date: Tue, 8 Jan 2019 16:13:09 +0100	[thread overview]
Message-ID: <20190108151309.GE11492@linux.fritz.box> (raw)
In-Reply-To: <b6df06a8-4a68-e4ed-2101-d0e30759c8e0@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1735 bytes --]

Am 08.01.2019 um 15:51 hat Eric Blake geschrieben:
> On 1/8/19 6:16 AM, Kevin Wolf wrote:
> > Unconditionally setting optind = 1 looks fine. I would, however, quote a
> > different part of the glibc man page (in addition or instead of the
> > paragraph you already quoted):
> > 
> >     The  variable  optind is the index of the next element to be
> >     processed in argv.  The system initializes this value to 1.  The
> >     caller can reset it to 1 to restart scanning of the same argv, or
> >     when scanning a new argument vector.
> > 
> > This makes it pretty clear that optind = 1 is fine for our case with
> > glibc. The FreeBSD man page still suggests that we need optreset = 1, so
> > I suppose we'd end up with something like:
> > 
> > ...
> > optind = 1;
> > #ifdef __FreeBSD__
> > optreset = 1;
> > #endif
> 
> If you really want to set optreset for BSD systems, I'd do a configure
> probe for whether optreset exists, and if so set it for ALL platforms
> that have optreset, not just for __FreeBSD__.  (That, and checkpatch.pl
> will gripe if you don't do it that way).
> 
> But I'm leaning towards not bothering with optreset UNLESS someone
> proves they have a case where it actually matters.

I don't mind either way as long as it works. Using optreset would be
following the spec by the letter.

In fact, I had already applied this patch because it's correct even if
possibly incomplete, depending on your interpretation, but I decided to
reply instead because the commit message didn't really describe that
optreset = 1 is correct for glibc, but that optreset = 0 is necessary in
some other case (which is irrelevant here). So the commit message was my
main point.

Kevin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

  reply	other threads:[~2019-01-08 15:13 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-03  9:47 [Qemu-devel] [PATCH v2] qemu-io: Reinitialize optind to 1 (not 0) before parsing inner command Richard W.M. Jones
2019-01-03  9:47 ` Richard W.M. Jones
2019-01-03 19:46   ` Eric Blake
2019-01-07 17:17   ` Max Reitz
2019-01-07 17:46     ` Eric Blake
2019-01-07 17:50       ` Max Reitz
2019-01-07 17:59         ` Eric Blake
2019-01-07 18:14           ` Max Reitz
2019-01-07 18:45             ` Eric Blake
2019-01-09 12:30               ` Max Reitz
2019-01-07 18:40         ` Richard W.M. Jones
2019-01-08 12:16           ` Kevin Wolf
2019-01-08 14:51             ` Eric Blake
2019-01-08 15:13               ` Kevin Wolf [this message]
2019-01-08 15:35                 ` Richard W.M. Jones
2019-01-09 12:33               ` Max Reitz

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=20190108151309.GE11492@linux.fritz.box \
    --to=kwolf@redhat.com \
    --cc=eblake@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=rjones@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.