From: Wolfgang Denk <wd@denx.de>
To: Sean Anderson <seanga2@gmail.com>
Cc: "Roland Gaudig" <roland.gaudig-oss@weidmueller.com>,
u-boot@lists.denx.de, "Simon Glass" <sjg@chromium.org>,
"Roland Gaudig" <roland.gaudig@weidmueller.com>,
"Alex Nemirovsky" <alex.nemirovsky@cortina-access.com>,
"Bin Meng" <bmeng.cn@gmail.com>,
"Heinrich Schuchardt" <xypron.glpk@gmx.de>,
"Marek Behún" <marek.behun@nic.cz>,
"Patrick Delaunay" <patrick.delaunay@foss.st.com>,
"Rayagonda Kokatanur" <rayagonda.kokatanur@broadcom.com>,
"Robert Marko" <robert.marko@sartura.hr>,
"Stefan Bosch" <stefan_b@posteo.net>,
"Weijie Gao" <weijie.gao@mediatek.com>
Subject: Re: [PATCH 0/3] cmd: setexpr: add fmt format string operation
Date: Tue, 29 Jun 2021 17:13:33 +0200 [thread overview]
Message-ID: <103545.1624979613@gemini.denx.de> (raw)
In-Reply-To: <19b6eeea-2aad-972b-aeeb-8959aab17d7a@gmail.com>
Dear Sean,
In message <19b6eeea-2aad-972b-aeeb-8959aab17d7a@gmail.com> you wrote:
>
> The issue with this is twofold. First, there is no portable way to
> construct a va_list from C code. So the likely way to do this would be
> to set an arbitrary limit, and then just pass the arguments in. E.g.
> something like
We already have an argument list: it's what's being passed to the
"setexpr" command, minus the initial arguments.
> snprintf(buf, sizeof(buf), argv[3], argc >= 4 ? argv[4] : NULL, /* etc */);
Why this test on argc? If it's less than 4, argv[4] should be NULL
anyway.
> but of course there is no way to check that the format string matches
> the correct number of arguments. This is a pretty big footgun.
You have this problem always when you have user provided format
strings and arguments. We don't have to re-invent the wheel here.
I repeat myself: maybe we should have a look at bash's
implementation of the printf builtin command? there I get for
example this:
$ printf "%d %d %d\n" 3
3 0 0
$ printf "%d %d %d\n" foo bar
-bash: printf: foo: invalid number
-bash: printf: bar: invalid number
0 0 0
> The other problem is that things like `%d` expect a number and not a
> string. So you would have to reimplement snprintf anyway so that it
> expects all of its arguments to be strings, and calls strtoul as
> appropriate. And considering that the *printf functions take 5k
> already, this reimplementation may add a significant amount of code.
> For this reason, I'd much prefer to just have `hex` and `dec` functions
> which do the appropriate conversions.
Eventually the format checking can be kept out of the generic
*printf() code; it could then be optional/configurable with the
"fmt" option in the setexpr command.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Every program has at least one bug and can be shortened by at least
one instruction -- from which, by induction, one can deduce that
every program can be reduced to one instruction which doesn't work.
next prev parent reply other threads:[~2021-06-29 15:13 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-28 15:17 [PATCH 0/3] cmd: setexpr: add fmt format string operation Roland Gaudig
2021-06-28 15:17 ` [PATCH 1/3] " Roland Gaudig
2021-06-28 17:39 ` Rasmus Villemoes
2021-06-29 8:44 ` Wolfgang Denk
2021-06-29 8:41 ` Wolfgang Denk
2021-06-28 15:17 ` [PATCH 2/3] doc: usage: add description for setexpr command Roland Gaudig
2021-07-05 15:29 ` Simon Glass
2021-06-28 15:17 ` [PATCH 3/3] test: cmd: setexpr: add tests for format string operations Roland Gaudig
2021-07-05 15:29 ` Simon Glass
2021-06-29 8:37 ` [PATCH 0/3] cmd: setexpr: add fmt format string operation Wolfgang Denk
2021-06-29 9:41 ` Roland Gaudig (OSS)
2021-06-29 10:34 ` Marek Behun
2021-06-29 10:40 ` Wolfgang Denk
2021-06-30 8:30 ` Roland Gaudig (OSS)
2021-06-29 13:57 ` Sean Anderson
2021-06-29 15:13 ` Wolfgang Denk [this message]
2021-06-30 16:17 ` Sean Anderson
2021-06-30 17:11 ` Marek Behún
2021-07-02 10:50 ` Wolfgang Denk
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=103545.1624979613@gemini.denx.de \
--to=wd@denx.de \
--cc=alex.nemirovsky@cortina-access.com \
--cc=bmeng.cn@gmail.com \
--cc=marek.behun@nic.cz \
--cc=patrick.delaunay@foss.st.com \
--cc=rayagonda.kokatanur@broadcom.com \
--cc=robert.marko@sartura.hr \
--cc=roland.gaudig-oss@weidmueller.com \
--cc=roland.gaudig@weidmueller.com \
--cc=seanga2@gmail.com \
--cc=sjg@chromium.org \
--cc=stefan_b@posteo.net \
--cc=u-boot@lists.denx.de \
--cc=weijie.gao@mediatek.com \
--cc=xypron.glpk@gmx.de \
/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.