From: Willy Tarreau <w@1wt.eu>
To: "Thomas Weißschuh" <thomas@t-8ch.de>
Cc: Vincent Dagonneau <v@vda.io>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 4/4] tools/nolibc: add tests for the integer limits in stdint.h
Date: Tue, 21 Feb 2023 18:44:44 +0100 [thread overview]
Message-ID: <Y/UDDIijmryKRIkq@1wt.eu> (raw)
In-Reply-To: <3db10837-b632-4df6-9d5f-199fca0eca87@t-8ch.de>
On Tue, Feb 21, 2023 at 05:34:01PM +0000, Thomas Weißschuh wrote:
> > diff --git a/tools/testing/selftests/nolibc/nolibc-test.c b/tools/testing/selftests/nolibc/nolibc-test.c
> > index 882140508d56..ceaf60075331 100644
> > --- a/tools/testing/selftests/nolibc/nolibc-test.c
> > +++ b/tools/testing/selftests/nolibc/nolibc-test.c
> > @@ -561,7 +561,67 @@ int run_syscall(int min, int max)
> > CASE_TEST(waitpid_child); EXPECT_SYSER(1, waitpid(getpid(), &tmp, WNOHANG), -1, ECHILD); break;
> > CASE_TEST(write_badf); EXPECT_SYSER(1, write(-1, &tmp, 1), -1, EBADF); break;
> > CASE_TEST(write_zero); EXPECT_SYSZR(1, write(1, &tmp, 0)); break;
> > - case __LINE__:
> > + CASE_TEST(limit_int8_max); EXPECT_EQ(1, INT8_MAX, (int8_t) 0x7f); break;
> > + CASE_TEST(limit_int8_min); EXPECT_EQ(1, INT8_MIN, (int8_t) 0x80); break;
> > + CASE_TEST(limit_uint8_max); EXPECT_EQ(1, UINT8_MAX, (uint8_t) 0xff); break;
> > + CASE_TEST(limit_int16_max); EXPECT_EQ(1, INT16_MAX, (int16_t) 0x7fff); break;
> > + CASE_TEST(limit_int16_min); EXPECT_EQ(1, INT16_MIN, (int16_t) 0x8000); break;
> > + CASE_TEST(limit_uint16_max); EXPECT_EQ(1, UINT16_MAX, (uint16_t) 0xffff); break;
> > + CASE_TEST(limit_int32_max); EXPECT_EQ(1, INT32_MAX, (int32_t) 0x7fffffff); break;
> > + CASE_TEST(limit_int32_min); EXPECT_EQ(1, INT32_MIN, (int32_t) 0x80000000); break;
> > + CASE_TEST(limit_uint32_max); EXPECT_EQ(1, UINT32_MAX, (uint32_t) 0xffffffff); break;
> > + CASE_TEST(limit_int64_max); EXPECT_EQ(1, INT64_MAX, (int64_t) 0x7fffffffffffffff); break;
> > + CASE_TEST(limit_int64_min); EXPECT_EQ(1, INT64_MIN, (int64_t) 0x8000000000000000); break;
> > + CASE_TEST(limit_uint64_max); EXPECT_EQ(1, UINT64_MAX, (uint64_t) 0xffffffffffffffff); break;
> > + CASE_TEST(limit_int_least8_max); EXPECT_EQ(1, INT_LEAST8_MAX, (int_least8_t) 0x7f); break;
> > + CASE_TEST(limit_int_least8_min); EXPECT_EQ(1, INT_LEAST8_MIN, (int_least8_t) 0x80); break;
> > + CASE_TEST(limit_uint_least8_max); EXPECT_EQ(1, UINT_LEAST8_MAX, (uint_least8_t) 0xff); break;
> > + CASE_TEST(limit_int_least16_max); EXPECT_EQ(1, INT_LEAST16_MAX, (int_least16_t) 0x7fff); break;
> > + CASE_TEST(limit_int_least16_min); EXPECT_EQ(1, INT_LEAST16_MIN, (int_least16_t) 0x8000); break;
> > + CASE_TEST(limit_uint_least16_max); EXPECT_EQ(1, UINT_LEAST16_MAX, (uint_least16_t) 0xffff); break;
> > + CASE_TEST(limit_int_least32_max); EXPECT_EQ(1, INT_LEAST32_MAX, (int_least32_t) 0x7fffffff); break;
> > + CASE_TEST(limit_int_least32_min); EXPECT_EQ(1, INT_LEAST32_MIN, (int_least32_t) 0x80000000); break;
> > + CASE_TEST(limit_uint_least32_max); EXPECT_EQ(1, UINT_LEAST32_MAX, (uint_least32_t) 0xffffffffU); break;
> > + CASE_TEST(limit_int_fast8_max); EXPECT_EQ(1, INT_FAST8_MAX, (int_fast8_t) 0x7f); break;
> > + CASE_TEST(limit_int_fast8_min); EXPECT_EQ(1, INT_FAST8_MIN, (int_fast8_t) 0x80); break;
> > + CASE_TEST(limit_uint_fast8_max); EXPECT_EQ(1, UINT_FAST8_MAX, (uint_fast8_t) 0xff); break;
> > +#if __SIZEOF_LONG__ == 8
> > + CASE_TEST(limit_int_least64_min); EXPECT_EQ(1, INT_LEAST64_MIN, (int_least64_t) 0x8000000000000000LL); break;
> > + CASE_TEST(limit_int_least64_max); EXPECT_EQ(1, INT_LEAST64_MAX, (int_least64_t) 0x7fffffffffffffffLL); break;
> > + CASE_TEST(limit_uint_least64_max); EXPECT_EQ(1, UINT_LEAST64_MAX, (uint_least64_t) 0xffffffffffffffffULL); break;
>
> The _least64 tests should also apply to 32bit, no?
> And moved before the _fast8 tests.
Just thinking loud, it seems to me that all of these _least/_fast ones
can in fact be reliably checked against INT_*, LONG_* and SIZE_MAX. Given
that these ones are already tested, maybe we can just get rid of the ifdef
around all the least/fast and map them to the ones we already test ? That
would possibly remove duplication and make it more readable.
Willy
next prev parent reply other threads:[~2023-02-21 17:44 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-20 20:20 [PATCH v4 0/4] tools/nolibc: Adding stdint.h, more integer types and tests Vincent Dagonneau
2023-02-20 20:20 ` [PATCH v5 1/4] tools/nolibc: add stdint.h Vincent Dagonneau
2023-02-20 20:20 ` [PATCH v5 2/4] tools/nolibc: add integer types and integer limit macros Vincent Dagonneau
2023-02-21 17:40 ` Thomas Weißschuh
2023-02-23 0:35 ` Vincent Dagonneau
2023-02-20 20:20 ` [PATCH v5 3/4] tools/nolibc: enlarge column width of tests Vincent Dagonneau
2023-02-20 20:20 ` [PATCH v5 4/4] tools/nolibc: add tests for the integer limits in stdint.h Vincent Dagonneau
2023-02-21 17:34 ` Thomas Weißschuh
2023-02-21 17:44 ` Willy Tarreau [this message]
2023-02-23 0:38 ` Vincent Dagonneau
2023-02-23 0:58 ` Vincent Dagonneau
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=Y/UDDIijmryKRIkq@1wt.eu \
--to=w@1wt.eu \
--cc=linux-kernel@vger.kernel.org \
--cc=thomas@t-8ch.de \
--cc=v@vda.io \
/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