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

Re: [PATCH] fast-export: avoid NULL pointer arithmetic

From
Junio C Hamano <gitster@pobox.com>
Date
May 10, 2018, 10:51 UTC
Message-ID
<xmqqo9hniy1v.fsf@gitster-ct.c.googlers.com>
In-Reply-To
<99d443cd-e817-7db5-f758-bf4cf47f7c06@web.de>
René Scharfe <l.s.r@web.de> writes:
Show 9 quoted lines
> The standard says about uintptr_t that "any valid pointer to void can
> be converted to this type, then converted back to pointer to void, and
> the result will compare equal to the original pointer".  So void * ->
> uintptr_t -> void * is a proper roundtrip, but that doesn't imply that
> casting arbitrary uintptr_t values to void * would be lossless.
>
> I don't know an architecture where this would bite us, but I wonder if
> there is a cleaner way.  Perhaps changing the type of the decoration
> member of struct decoration_entry in decorate.h to uintptr_t?

In order to ensure "void * -> uintptr_t -> void *" roundtrip holds, the implementation would guarantee that uintptr_t is wider than void*, so what you suggest technically makes sense. We should be able to store any pointer in the field. And we should be able to store any value of an unsigned integral type that is narrower than uintptr_t.

But it somehow feels backwards in spirit to me, as the reason why we use "void *" there in the decoration field is because we expect that we'd have a pointer to some struture most of the time, and we have to occasionally store a small integer there. So I'd naively expect that

	uint32_t mark = 23;
	de->decoration = (void *)mark;
would be a good way to store mark #23 in the field and
	uint32_t mark;
	mark = (typeof(mark))de->decoration;

would be a good way to read it off of the "void *" field. Of course, this assume that (void *) is at least as wide as 32-bit and it also ignores the standard ;-)

This is an unrelated tangent but the mark-to-ptr() and ptr-to-mark() implementations feel wasteful, especially when we worry about 32-bit archs. A naive platform implementation of

	(uint32_t *)mark - (uint32_t *)NULL;

would be ((uintptr_t)mark) / 4, i.e. the de->decoration field will always have two LSB clear and only utilize top 30-bit to represent the value of mark.

Previous: René ScharfeNext: René Scharfe
Message 4 of 16 in “fast-export: avoid NULL pointer arithmetic”
  1. fast-export: avoid NULL pointer arithmeticRené Scharfe, May 9, 2018
  2. Johannes SchindelinMay 9, 2018
  3. René ScharfeMay 10, 2018
  4. Junio C HamanoMay 10, 2018
  5. René ScharfeMay 10, 2018
  6. Junio C HamanoMay 11, 2018
  7. Junio C HamanoMay 11, 2018
  8. Duy NguyenMay 11, 2018
  9. Jeff KingMay 11, 2018
  10. Duy NguyenMay 11, 2018
  11. Duy NguyenMay 11, 2018
  12. Jeff KingMay 11, 2018
  13. René ScharfeMay 12, 2018
  14. René ScharfeMay 12, 2018
  15. Junio C HamanoMay 14, 2018
  16. René ScharfeMay 15, 2018

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.