From: Tejun Heo <tj@kernel.org>
To: "lilingfeng (A)" <lilingfeng3@huawei.com>
Cc: linux-kernel@vger.kernel.org, jack@suse.cz,
bingjingc@synology.com, ebiggers@google.com,
james.smart@broadcom.com, houtao1@huawei.com,
yi.zhang@huawei.com, yangerkun@huawei.com, yukuai3@huawei.com
Subject: Re: [PATCH-next] lib: parser: optimize match_NUMER apis to use local array
Date: Sat, 10 Dec 2022 08:37:57 -1000 [thread overview]
Message-ID: <Y5TSBUxQPhvngK7J@slm.duckdns.org> (raw)
In-Reply-To: <8ed91647-f429-493e-b4e1-1f6bf11c228b@huawei.com>
Hello,
On Sat, Dec 10, 2022 at 10:51:11AM +0800, lilingfeng (A) wrote:
> Thank you for your advice. But I think match_number() is aimed to turn the
> string to num, so maybe it's better to return an error code rather than
> using match_stlcpy() to truncate it to give a wrong num when the string
> is too long to store.
Yeah, so, you check the the returned length and return an error code if the
returned value is too long for the buffer. That's how this family of
functions get error-checked.
> > > +{
> > > + size_t len = s->to - s->from;
> > > +
> > > + if (!s->from)
> > > + return -EINVAL;
> > If we use match_strlcpy() we lose the above null check but given that other
> > match_*() functions aren't doing it, this likely shouldn't matter.
>
> Like this:
> match_strdup
> kmemdup_nul
> if (!s) // null check has been done here
> return NULL
> So I think null check may be necessary.
I mean, it's there now but other match functions don't, so it's unlikely
that the NULL check is necessary unless we're saying "parsing this type
string can encounter NULL inputs but these don't". That said, it doesn't
really matter. If you wanna keep the NULL check, do so before calling
strlcpy.
Thanks.
--
tejun
prev parent reply other threads:[~2022-12-10 18:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-09 6:34 Li Lingfeng
2022-12-09 16:57 ` Tejun Heo
2022-12-10 2:51 ` lilingfeng (A)
2022-12-10 18:37 ` Tejun Heo [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=Y5TSBUxQPhvngK7J@slm.duckdns.org \
--to=tj@kernel.org \
--cc=bingjingc@synology.com \
--cc=ebiggers@google.com \
--cc=houtao1@huawei.com \
--cc=jack@suse.cz \
--cc=james.smart@broadcom.com \
--cc=lilingfeng3@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=yangerkun@huawei.com \
--cc=yi.zhang@huawei.com \
--cc=yukuai3@huawei.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
all inboxes | Powered by JetHome®