From: Shuah Khan <skhan@linuxfoundation.org>
To: "Thomas Weißschuh" <linux@weissschuh.net>
Cc: Willy Tarreau <w@1wt.eu>, Shuah Khan <shuah@kernel.org>,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
Shuah Khan <skhan@linuxfoundation.org>
Subject: Re: [PATCH 1/2] tools/nolibc: add support for [v]sscanf()
Date: Fri, 2 Aug 2024 15:20:51 -0600 [thread overview]
Message-ID: <fc8a6e83-98fa-4809-8b05-ea9f94dd2c71@linuxfoundation.org> (raw)
In-Reply-To: <5db920e0-51e8-48d9-b0ae-95479e875fad@t-8ch.de>
On 8/2/24 09:48, Thomas Weißschuh wrote:
> On 2024-07-31 17:01:09+0000, Shuah Khan wrote:
>> On 7/31/24 12:32, Thomas Weißschuh wrote:
>>> The implementation is limited and only supports numeric arguments.
>>
>> I would like to see more information in here. Why is this needed
>> etc. etc.
>
> Ack.
>
>>>
>>> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
>>> ---
>>> tools/include/nolibc/stdio.h | 93 ++++++++++++++++++++++++++++
>>> tools/testing/selftests/nolibc/nolibc-test.c | 59 ++++++++++++++++++
>>> 2 files changed, 152 insertions(+)
>>>
>>> diff --git a/tools/include/nolibc/stdio.h b/tools/include/nolibc/stdio.h
>>> index c968dbbc4ef8..d63c45c06d8e 100644
>>> --- a/tools/include/nolibc/stdio.h
>>> +++ b/tools/include/nolibc/stdio.h
>>> @@ -348,6 +348,99 @@ int printf(const char *fmt, ...)
>>> return ret;
>>> }
>>> +static __attribute__((unused))
>>> +int vsscanf(const char *str, const char *format, va_list args)
>>
>> Is there a reason why you didn't use the same code in lib/vsprintf.c?
>> You could simply duplicate the code here?
>
> lib/vsprintf.c is GPL-2.0-only while nolibc is LGPL-2.1 OR MIT,
> so code reuse isn't really possible.
> Furthermore I think the vsprintf.c implements the custom kernel formats,
> while nolibc should use posix ones.
Ack.
>
>> With all these libc functionality added, it isn't nolibc looks like :)
>
> Well :-)
>
> The main motivation is to provide kselftests compatibility.
> Maybe Willy disagrees.
>
>>> +{
>>> +done:
>>> + return matches;
>>> +}
>>> +
>>> +static __attribute__((unused, format(scanf, 2, 3)))
>>> +int sscanf(const char *str, const char *format, ...)
>>> +{
>>> + va_list args;
>>> + int ret;
>>> +
>>> + va_start(args, format);
>>> + ret = vsscanf(str, format, args);
>>> + va_end(args);
>>> + return ret;
>>> +}
>>> +
>>> static __attribute__((unused))
>>> void perror(const char *msg)
>>> {
>>> diff --git a/tools/testing/selftests/nolibc/nolibc-test.c b/tools/testing/selftests/nolibc/nolibc-test.c
>>> index 093d0512f4c5..addbceb0b276 100644
>>> --- a/tools/testing/selftests/nolibc/nolibc-test.c
>>> +++ b/tools/testing/selftests/nolibc/nolibc-test.c
>>> @@ -1277,6 +1277,64 @@ static int expect_vfprintf(int llen, int c, const char *expected, const char *fm
>>> return ret;
>>> }
>>> +static int test_scanf(void)
Is there a rationale for the return values 1 - 14. It will be
easier to understand if there are comments in the code.
>>> +{
>>> + unsigned long long ull;
>>> + unsigned long ul;
>>> + unsigned int u;
>>> + long long ll;
>>> + long l;
>>> + void *p;
>>> + int i;
>>> +
>>> + if (sscanf("", "foo") != EOF)
>>> + return 1;
>>> +
>>> + if (sscanf("foo", "foo") != 0)
>>> + return 2;
>>> +
>>> + if (sscanf("123", "%d", &i) != 1)
>>> + return 3;>>> +
>>> + if (i != 123)
>>> + return 4;
>>> +
>>> + if (sscanf("a123b456c0x90", "a%db%uc%p", &i, &u, &p) != 3)
>>> + return 5;
>>> +
>>> + if (i != 123)
>>> + return 6;
>>> +
>>> + if (u != 456)
>>> + return 7;
>>> +
>>> + if (p != (void *)0x90)
>>> + return 8;
>>> +
>>> + if (sscanf("a b1", "a b%d", &i) != 1)
>>> + return 9;
>>> +
>>> + if (i != 1)
>>> + return 10;
>>> +
>>> + if (sscanf("a%1", "a%%%d", &i) != 1)
>>> + return 11;
>>> +
>>> + if (i != 1)
>>> + return 12;
>>> +
>>> + if (sscanf("1|2|3|4|5|6",
>>> + "%d|%ld|%lld|%u|%lu|%llu",
>>> + &i, &l, &ll, &u, &ul, &ull) != 6)
>>> + return 13;
>>> +
>>> + if (i != 1 || l != 2 || ll != 3 ||
>>> + u != 4 || ul != 5 || ull != 6)
>>> + return 14;
>>> +
>>> + return 0;
>>
>> Can we simplify this code? It is hard to read code with too
>> many conditions. Maybe defining an array test conditions
>> instead of a series ifs.
>
> I tried that and didn't find a way.
> Any pointers are welcome.
I played with this some and couldn't think of way to simplify
this without making it hard to read. It would help adding
comments though.
thanks,
-- Shuah
next prev parent reply other threads:[~2024-08-02 21:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-31 18:32 [PATCH 0/2] tools/nolibc: add support for [v]sscanf() Thomas Weißschuh
2024-07-31 18:32 ` [PATCH 1/2] " Thomas Weißschuh
2024-07-31 23:01 ` Shuah Khan
2024-08-02 15:48 ` Thomas Weißschuh
2024-08-02 21:20 ` Shuah Khan [this message]
2024-08-03 10:16 ` Willy Tarreau
2024-07-31 18:32 ` [PATCH 2/2] Revert "selftests: kselftest: Fix build failure with NOLIBC" Thomas Weißschuh
2024-07-31 22:56 ` [PATCH 0/2] tools/nolibc: add support for [v]sscanf() Shuah Khan
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=fc8a6e83-98fa-4809-8b05-ea9f94dd2c71@linuxfoundation.org \
--to=skhan@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux@weissschuh.net \
--cc=shuah@kernel.org \
--cc=w@1wt.eu \
/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