On Mon, Mar 12, 2018 at 1:21 PM, Greg Kurz <gr...@kaod.org> wrote:
> On Mon, 12 Mar 2018 13:08:29 +0000
> Daniel P. Berrangé <berra...@redhat.com> wrote:
>
>> On Mon, Mar 12, 2018 at 02:02:29PM +0100, Greg Kurz wrote:
>> > On Mon, 12 Mar 2018 07:12:52 -0500
>> > Eric Blake <ebl...@redhat.com> wrote:
>> >
>> > > On 03/11/2018 03:12 PM, Nia Alarie wrote:
>> > > > Signed-off-by: Nia Alarie <nia.ala...@gmail.com>
>> > > > ---
>> > > > hw/9pfs/9p.c | 12 ++++++++++--
>> > > > 1 file changed, 10 insertions(+), 2 deletions(-)
>> > > >
>> > >
>> > > > } else if (perm & P9_STAT_MODE_LINK) {
>> > > > - int32_t ofid = atoi(extension.data);
>> > > > - V9fsFidState *ofidp = get_fid(pdu, ofid);
>> > > > + long ofid;
>> > > > + V9fsFidState *ofidp;
>> > > > +
>> > > > + if (qemu_strtol(extension.data, NULL, 10, &ofid) ||
>> > > > + ofid > INT32_MAX || ofid < INT32_MIN) {
>> > >
>> > > Dan has a pending patch that will add qemu_strtoi, which might be a
>> > > nicer fit for this situation:
>> > >
>> > > https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg00952.html
>> > >
>> > > int32_t is not necessarily int, but all platforms that compile qemu have
>> > > 'int32_t' and 'int' both at 32 bits, so it's simpler to change to 'int
>> > > ofid' and use Dan's function than it is to parse to long and then do
>> > > bounds checking. Except that Dan still needs to post an updated version
>> > > of his patch...
>> > >
>> >
>> > I wasn't aware of Dan's patch but I agree it would result in a nicer
>> > change for 9p. This being said, tomorrow is soft freeze... is there
>> > a chance Dan's patch reaches master anytime soon ?
>>
>> I just sent an update of my series. If it gets acked by Eric, I'd be able
>> to send a pull request today.
>>
>> Regards,
>> Daniel
>
> Great !
>
> Nia,
>
> Could you please respin your patch on top of Daniel's series, using
> qemu_strtoui() ?
>
> Thanks,
>
> --
> Greg
I'm a bit unclear on how this works so I thought I'd ask here before I
send any more patches - this is CCed to my mentors as well. It's
"tomorrow" now, but I don't understand how soft freezes work or the
process beyond "I send this patch to qemu-devel and people say if I
should re-send it with changes, or that it's been accepted" :)
There are several more conversions from ato* to qemu_strto* I'd like
to submit from now on. Should I send them as using qemu_strtol now, to
get them "out there" before my own personal deadlines, and send
further patches to convert them to qemu_strtoi later, or should I
submit patches that use qemu_strtoi? I'm not sure of the current
status of Daniel's patches.
Thank you.
