On 06.11.25 21:06, David Rowley wrote:
On Fri, 7 Nov 2025 at 07:33, Peter Eisentraut <[email protected]> wrote:
On 06.11.25 12:46, David Rowley wrote:
0002: MemSet / MemSetAligned macros. It's probably about time someone
made these disappear, but that's likely for another thread with more
research than I'd like to do here. I replaced "long" with "Size". I
also considered "uintptr_t", but after some reading of the C standard,
I settled on Size as it seems it's possible for platforms to exist
where the pointer width is smaller than the processor's width. I
suspect it might not matter for the platforms we support? Size could
also be smaller than the processor's width, but I feel that's less
likely.
I think size_t/Size could be misleading here. You're not measuring any
size, you're just chunking up the bytes to zero into something that we
thing the compiler or CPU can handle very efficiently.
So in a sense, using long isn't wrong here. It might well be the best
for this. If there is an aversion to using any long at all, why not
long long.
The point in changing this was that long isn't a good fit as it's not
64-bit on 64-bit Windows. My aim is to find a type with a width the
same as the processor's word size. long long tends to be 64-bit on
32-bit platforms, so doesn't seem a very good fit. Someone might argue
that doesn't matter now since we no longer have 4-byte Datums, but
IMO, this isn't any reason to make things even worse for 32-bit
builds.
Yeah you're right. If we cared a lot about MemSet's longevity, I would
suggest making a new type for this, but that would leak into all users
of c.h, so maybe not.
I do suggest some kind of comment, that we're using size_t as a
convenient proxy for the most suitable chunk/step size for the platform,
not to actually measure a size.
