git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 1/3] t-ctype: allow NUL anywhere in the specification string

From
Jeff King <peff@peff.net>
Date
Feb 25, 2024, 21:00 UTC
Message-ID
<20240225210038.GA3368483@coredump.intra.peff.net>
In-Reply-To
<CAPig+cThAYjf4DU40dY9jCnjL0FsVpYFhcsj9YdvW2Q=c=ZDBg@mail.gmail.com>
On Sun, Feb 25, 2024 at 01:41:30PM -0500, Eric Sunshine wrote:
Show 30 quoted lines
> On Sun, Feb 25, 2024 at 1:28 PM René Scharfe <l.s.r@web.de> wrote:
> > Am 25.02.24 um 19:05 schrieb Eric Sunshine:
> > > On Sun, Feb 25, 2024 at 6:27 AM René Scharfe <l.s.r@web.de> wrote:
> > >> Getting the string size using sizeof only works in a macro and with a
> > >> string constant, but that's exactly what we have and I don't see it
> > >> changing anytime soon.
> > >>
> > >>  /* Macro to test a character type */
> > >>  #define TEST_CTYPE_FUNC(func, string) \
> > >
> > > Taking into consideration the commit message warning about string
> > > constants, would it make sense to update the comment to mention that
> > > limitation?
> > >
> > >     /* Test a character type. (Only use with string constants.) */
> > >     #define TEST_CTYPE_FUNC(func, string) \
> > >>  static void test_ctype_##func(void) { \
> > >>         for (int i = 0; i < 256; i++) { \
> > >> +               int expect = !!memchr(string, i, sizeof(string) - 1); \
> >
> > I think the temptation to pass a string pointer is low -- if only
> > because there aren't any in this file.  But adding such a warning
> > can't hurt, so yeah, why not?
> 
> The patch just posted[1] by SZEDER reminded me that, on this project,
> we assume that the compiler is smart enough to replace
> `strlen("string-literal")` with the constant `15`, so rather than
> worrying about updating comment to mention the sizeof() limitation,
> you could perhaps just use `strlen(string)` instead of
> `sizeof(string)-1`?

That would defeat the advertised purpose that we can handle embedded NULs, though. Whereas with sizeof(), I think a literal like "foo\0bar" would still have length 8.

-Peff
Previous: Eric SunshineNext: Eric Sunshine
Message 6 of 30 in “t-ctype: simplify unit test definitions”
  1. 0/3 t-ctype: simplify unit test definitionsRené Scharfe, Feb 25, 2024
  2. 1/3 t-ctype: allow NUL anywhere in the specification stringRené Scharfe, Feb 25, 2024
  3. Eric SunshineFeb 25, 2024
  4. René ScharfeFeb 25, 2024
  5. Eric SunshineFeb 25, 2024
  6. Jeff KingFeb 25, 2024
  7. Eric SunshineFeb 25, 2024
  8. 2/3 t-ctype: avoid duplicating class namesRené Scharfe, Feb 25, 2024
  9. 3/3 t-ctype: do one test per class and charRené Scharfe, Feb 25, 2024
  10. Christian CouderFeb 26, 2024
  11. René ScharfeFeb 26, 2024
  12. Junio C HamanoFeb 26, 2024
  13. Josh SteadmonFeb 26, 2024
  14. Christian CouderFeb 27, 2024
  15. René ScharfeMar 2, 2024
  16. Christian CouderMar 4, 2024
  17. René ScharfeMar 6, 2024
  18. Josh SteadmonMar 4, 2024
  19. Junio C HamanoMar 4, 2024
  20. 0/4 t-ctype: simplify unit test definitionsRené Scharfe, Mar 3, 2024
  21. 2/4 t-ctype: simplify EOF checkRené Scharfe, Mar 3, 2024
  22. 3/4 t-ctype: align output of iRené Scharfe, Mar 3, 2024
  23. 4/4 t-ctype: avoid duplicating class namesRené Scharfe, Mar 3, 2024
  24. Phillip WoodMar 4, 2024
  25. René ScharfeMar 6, 2024
  26. Phillip WoodMar 8, 2024
  27. Phillip WoodMar 9, 2024
  28. René ScharfeMar 10, 2024
  29. 1/4 t-ctype: allow NUL anywhere in the specification stringRené Scharfe, Mar 3, 2024
  30. Christian CouderMar 4, 2024

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.