Maybe npy_uintp. I'm pretty sure both work here for twos complement integers, but I needed to think about it.

Note that it is later cast to npy_uintp in npy_is_aligned.

Only bitwise operations are involved, so it should be exactly the same.

I think there is an assumption of multiples of powers of two, together with twos complement arithmetic, built in here. AFAICT, there are no false positive, but perhaps some false negatives. @juliantaylor @seberg Thoughts?

I don't see any arithmetic here, only bitwise OR operations. Whether the integer is considered signed or unsigned doesn't come into play.

Well the bitwise or is used together with arrhythmic stuff later since it is used in npy_is_aligned. Did not think about it long, but I think you are right Chuck. I guess npy_is_aligned might explain it a bit more?

Not sure if twos complement has anything to do with it though.

"arrythmic"? :-)

More seriously, I don't know what you are bothering about. First data is cast to npy_intp(this is an exact bitcast), some bitwise operations are done on the signed integer (they are agnostic wrt signedness, they just operate on individual bits), then the result is cast back to void* (this is an exact bitcast), then it is finally cast to npy_uintp (again an exact bitcast).

There is zero reason to believe that the intermediate cast to npy_intp is any potential cause for trouble.

Well, if this errs too much on the safe side (no idea if it does). I guess placing the npy_is_aligned check into the loop here instead should work and probably not be a lot of overhead. (Plus this is the flags calculation, right? so it doesn't happen very often anyway). Or am I missing something? Plus it might be a bit less mind boggling.

EDIT: Frankly, nvm, I bet for all practical purposes, this just always works.

Yeah, it has been there a long time. I think it basically gives the largest power of two that divides the GCD. For non-powers of two I'm not sure how well it works. But we have lived with it for a long time. Might be worth a note, however.

Some googling suggests that the C standard says that alignments must be powers of two. (I wasn't able to find the exact quote though). In that case, the special casing in npy_is_aligned is unnecessary, and we can just assume it is a power of two.

I'll add a note in any case, I think this is the 3rd time now that I've puzzled out what this code does.

I was planning to sleep on it :) I think when all is done, it will be OK for its intended application, but I want to understand it...

I think you're right that this assumes a twos-complement representation of signed integers, even though the C standard explicitly allows others like ones-complement. I'm not sure we care, because in practice all modern computers use two's complement, and because all this pointer bit-twiddling is C-implementation-dependent anyway.

Here's my understanding: We are trying to compute whether (data + n*stride)%alignment == 0 for all integers n. First, assuming alignment is a power of two, and assuming twos-complement representation, simplify the %alignment == 0 to checking if the lowest log2(alignment) bits are 0. Next, use the fact that in twos complement representation, if x low order bits of data and stride are 0, then the x lower bits of data + n*stride must also be 0 for all n because of how binary addition works. Neither simplification is valid for negative values in ones-complement representation.

Casting the intp stride to uintp` and using uintp would avoid the signed twos-complement assumption, and the algorithm still works.

However, the representation/cast of data from pointer to uint is implementation defined too, so we are violating the standard anyway anytime we use bitwise ops on pointer values. (only arithmetic is allowed, I think). I don't see any alternative though, as far as I see there is no totally standard-compliant way to test alignment.

How do PyArray_ISALIGNED and IsUintAligned differ?

The former checks "true" alignment, the latter "uint" alignment.

We need uint alignment for the copy operations about 100 lines down.

So there are some structures that have no uint alignment?

Yes, that's one way to see it. Or, in pratice, those structs get assigned a uint alignment of 0.

The "uint" alignments are for use in the strided copy code, which only special-cases the 1,2,4,8, and 16 byte sizes. All other cases return a "uint" alignment of 0, which triggers memmove to be used instead.

I'll correct/update the docs to better describe what happens for non-power-of-two sized types.

What if it's a power of two greater than sizeof(uintmax_t)?

I'll have to rephrase, that's an inaccurate sentence. It also doesn't describe the fact that 16 bytes types have a uint alignment of 8, because that's what the copy code wants. Maybe:

"Uint" alignment depends on the size of a datatype. It is defined to be the
"True alignment" of the uint used in numpy's copy-code to copy the datatype,
or undefined/unaligned if there is no equivalent uint. Currently numpy uses 
uint8, uint16, uint32, uint64 and uint64 to copy data of size 1,2,4,8,16 bytes 
respectively, and all other sized datatypes cannot be uint aligned.

Counter-example:

>>> np.dtype('U1').alignment
4
>>> np.issubdtype('U1', np.flexible)
True

Don't you need to specify which meaning of "align" you are using here?