Re: size_t vs uintptr_t

2016-06-18 Thread Walter Bright via Digitalmars-d
On 6/17/2016 8:50 AM, Guillaume Boucher wrote: I was referring to this diff in the pull linked request: -private size_t _alignUp(size_t alignment)(size_t n) +private uintptr_t _alignUp(uintptr_t alignment)(uintptr_t n) size_t is the correct type. There is no reason to change it. Since

Re: size_t vs uintptr_t

2016-06-18 Thread Observer via Digitalmars-d
On Friday, 17 June 2016 at 15:50:41 UTC, Guillaume Boucher wrote: I was referring to this diff in the pull linked request: -private size_t _alignUp(size_t alignment)(size_t n) +private uintptr_t _alignUp(uintptr_t alignment)(uintptr_t n) size_t is the correct type. There is no reason to

Re: size_t vs uintptr_t

2016-06-17 Thread Guillaume Boucher via Digitalmars-d
I was referring to this diff in the pull linked request: -private size_t _alignUp(size_t alignment)(size_t n) +private uintptr_t _alignUp(uintptr_t alignment)(uintptr_t n) size_t is the correct type. There is no reason to change it.

Re: size_t vs uintptr_t

2016-06-15 Thread Walter Bright via Digitalmars-d
On 6/15/2016 9:31 AM, Steven Schveighoffer wrote: I think you guys are missing the point. I can check for 64-bit alignment by casting to ubyte: ((cast(ubyte)ptr) & 0x07) == 0 Walter: I don't see why the optimizer doesn't figure out the fastest way to do this, even with size_t. You are

Re: size_t vs uintptr_t

2016-06-15 Thread Steven Schveighoffer via Digitalmars-d
On 6/14/16 10:04 PM, deadalnix wrote: On Tuesday, 14 June 2016 at 23:19:12 UTC, Walter Bright wrote: On 6/14/2016 3:38 PM, Guillaume Boucher wrote: Isn't it guaranteed that x.sizeof >= x.alignof? (At least it is in C and C++.) So the alignment should be of type size_t and not of type

Re: size_t vs uintptr_t

2016-06-15 Thread Wyatt via Digitalmars-d
On Tuesday, 14 June 2016 at 21:59:32 UTC, Walter Bright wrote: Ok, I admit these are not likely to emerge. Not in desktop, server, or modern mobile phones, but I think there are some embedded platforms that have this concern. I know that's not a huge priority, but it's nice to be mindful of

Re: size_t vs uintptr_t

2016-06-15 Thread Ola Fosheim Grøstad via Digitalmars-d
On Wednesday, 15 June 2016 at 07:29:05 UTC, Ola Fosheim Grøstad wrote: On Tuesday, 14 June 2016 at 23:19:12 UTC, Walter Bright wrote: There is no conceivable case where alignment will be > 32 bits, nor not being a power of 2. Are you talking about hardware alignment or programmer specified

Re: size_t vs uintptr_t

2016-06-15 Thread Walter Bright via Digitalmars-d
On 6/14/2016 11:31 PM, Jacob Carlborg wrote: Ok, I admit these are not likely to emerge. But I'd like our code to be pedantically, nitpickingly correct, as well as self-documenting. I'd like that too, but as you said it's not an issue on any supported platforms. Therefore I think we have much

Re: size_t vs uintptr_t

2016-06-15 Thread Ola Fosheim Grøstad via Digitalmars-d
On Tuesday, 14 June 2016 at 23:19:12 UTC, Walter Bright wrote: There is no conceivable case where alignment will be > 32 bits, nor not being a power of 2. Are you talking about hardware alignment or programmer specified alignment?

Re: size_t vs uintptr_t

2016-06-15 Thread Walter Bright via Digitalmars-d
On 6/14/2016 8:43 PM, rikki cattermole wrote: size_t is defined in object.d. If we want to migrate fully, we will need to add a public import for uintptr_t. Otherwise it is not very consistent (and adds one more import across the board, when previously there was none.). I won't say you're

Re: size_t vs uintptr_t

2016-06-15 Thread Walter Bright via Digitalmars-d
On 6/14/2016 7:04 PM, deadalnix wrote: There are many cases in which alignment in 64bits. Not any that have anything to do with what we use alignment for.

Re: size_t vs uintptr_t

2016-06-15 Thread Jacob Carlborg via Digitalmars-d
On 2016-06-14 23:59, Walter Bright wrote: I recently remembered something I'd half-forgotten. A size_t is not guaranteed to be the same size as a pointer. A uintptr_t is. size_t and uintptr_t are the same for all platforms that D currently supports. But this may not always hold true, and

Re: size_t vs uintptr_t

2016-06-14 Thread rikki cattermole via Digitalmars-d
size_t is defined in object.d. If we want to migrate fully, we will need to add a public import for uintptr_t. Otherwise it is not very consistent (and adds one more import across the board, when previously there was none.).

Re: size_t vs uintptr_t

2016-06-14 Thread deadalnix via Digitalmars-d
On Tuesday, 14 June 2016 at 23:19:12 UTC, Walter Bright wrote: On 6/14/2016 3:38 PM, Guillaume Boucher wrote: Isn't it guaranteed that x.sizeof >= x.alignof? (At least it is in C and C++.) So the alignment should be of type size_t and not of type uintptr_t. Also in general

Re: size_t vs uintptr_t

2016-06-14 Thread Walter Bright via Digitalmars-d
On 6/14/2016 3:38 PM, Guillaume Boucher wrote: Isn't it guaranteed that x.sizeof >= x.alignof? (At least it is in C and C++.) So the alignment should be of type size_t and not of type uintptr_t. Also in general cast(uint)ptr%alignment is wrong since alignment does not need to be 32 bit.

Re: size_t vs uintptr_t

2016-06-14 Thread Guillaume Boucher via Digitalmars-d
On Tuesday, 14 June 2016 at 21:59:32 UTC, Walter Bright wrote: A related issue is I see much code of the form: cast(size_t)ptr & 3 to check alignment. A better (possibly faster) method is: cast(uint)ptr & 3 because even 64 bit CPUs often operate faster with 32 bit operations (thanks