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

Re: [PATCH] mem-pool: fix big allocations

From
René Scharfe <l.s.r@web.de>
Date
Dec 28, 2023, 16:05 UTC
Message-ID
<c5d35735-10e2-4b71-8fc7-6218e7002549@web.de>
In-Reply-To
<9aad15c8-8d3b-475b-bd44-5d24121cb793@gmail.com>
Am 28.12.23 um 16:10 schrieb Phillip Wood:
Show 22 quoted lines
> Hi René
>
> On 21/12/2023 23:13, René Scharfe wrote:
>> +#define check_ptr(a, op, b) check_int(((a) op (b)), ==, 1)
>> [...]
>> +static void t_calloc_100(struct mem_pool *pool)
>> +{
>> +    size_t size = 100;
>> +    char *buffer = mem_pool_calloc(pool, 1, size);
>> +    for (size_t i = 0; i < size; i++)
>> +        check_int(buffer[i], ==, 0);
>> +    if (!check_ptr(pool->mp_block, !=, NULL))
>> +        return;
>> +    check_ptr(pool->mp_block->next_free, <=, pool->mp_block->end);
>> +    check_ptr(pool->mp_block->next_free, !=, NULL);
>> +    check_ptr(pool->mp_block->end, !=, NULL);
>> +}
>
> It's great to see the unit test framework being used here. I wonder
> though if it would be simpler just to use
>
>     check(ptr != NULL)
Yes, that's better.
Show 10 quoted lines
> as I'm not sure what the check_ptr() macro adds. The diff at the end of
> this email shows a possible implementation of a check_ptr() macro for
> the unit test library. I'm wary of adding it though because I'm not sure
> printing the pointer values is actually very useful most of the
> time. I'm also concerned that the rules around pointer arithmetic and
> comparisons mean that many pointer tests such as
>
>     check_ptr(pool->mp_block->next_free, <=, pool->mp_block->end);
>
> will be undefined if they fail.

True, the compiler could legally emit mush when it finds out that the pointers are for different objects. And the error being fixed produces such unrelated pointer pairs -- oops.

This check is not important here, we can just drop it.
mem_pool_contains() has the same problem, by the way.

Restricting ourselves to only equality comparisons for pointers prevents some interesting sanity checks, though. Casting to intptr_t or uintptr_t would allow arbitrary comparisons without risk of undefined behavior, though. Perhaps that would make a check_ptr() macro viable and useful.

René
Previous: Phillip WoodNext: phillip.wood123@gmail.com
Message 5 of 12 in “mem-pool: fix big allocations”
  1. mem-pool: fix big allocationsRené Scharfe, Dec 21, 2023
  2. Elijah NewrenDec 24, 2023
  3. René ScharfeDec 24, 2023
  4. Phillip WoodDec 28, 2023
  5. René ScharfeDec 28, 2023
  6. phillip.wood123@gmail.comDec 28, 2023
  7. René ScharfeDec 28, 2023
  8. phillip.wood123@gmail.comDec 28, 2023
  9. René ScharfeDec 29, 2023
  10. mem-pool: fix big allocationsRené Scharfe, Dec 28, 2023
  11. phillip.wood123@gmail.comDec 28, 2023
  12. Taylor BlauJan 2, 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.