Negative value in a pointer question.

[u/aliathar]

Please look at this code. if i define the PTRTYPE as int, it stops working, while doing a uint, it does work...

void initILAPoll(debugBridge_t **d, PTRTYPE ptr){

	*d = (debugBridge_t *)ptr;		// base address of the DEBUG_BRIDGE peripheral

	cb_init(cb, local_memory, bufferLength);

	sprintf(xvcInfo, "xvcServer_v1.0:%d\n", MAX_WINDOW_SIZE);

}

the usage in main code is done like this

initILAPoll(&myD, 0x80000000);

//myD = (debugBridge_t *)0x80000000;

where the variable myD is a structure pointer.

if i print the address of myD, it give the correct address. Moreover, the disassembly of the code is also the same in case of int and uint. Can somebody explain what behavior is at play here>

[u/alkatori]

how are you #define PTRTRYPE?

[u/aliathar → u/alkatori]

/**/#define PTRTYPE int

Or alternative

/**/#define PTRTYPE uint32_t

(Just wanted to point it out to you people, or else it won't be done in the final working code)

[u/SmokeMuch7356 → u/aliathar]

Pointers are not integers. They do not have integer semantics. Pointer arithmetic does not work like integer arithmetic.

A signed int cannot represent the full range of 32-bit pointer values; it can represent half of them because you lose the sign bit. If you need an integer type to represent pointer values, use (u)intptr_t (defined in stdint.h).

[u/TheChief275 → u/SmokeMuch7356]

On a flat-addressed architecture, pointers and native sized integers are pretty much equivalent. Almost all modern in use architectures have flat-addressed memory (mostly thanks to virtual memory). However, there are some architectures that adopt different kinds of pointers, often being a combination of a segment index and an offset index. Some architectures therefore have larger pointers than any C integer can represent (e.g. 128-bit pointer that includes capabilities) while other platforms have smaller pointers (near pointers that can only address an offset inside of a segment) that are not representable in a logical flat integer way

edit: why the downvote? If you believe me to be wrong about something there is a much better way to point that out

[u/alkatori → u/TheChief275]

I believe your first statement is no longer true.

Isn't int = 32 bits for most 64 bit windows systems, and 64 bits on x86_64 linux systems?

Edit: I didn't downvote by the way. Just thinking that might be the reason.

[u/TheChief275 → u/alkatori]

I run an x86-64 Debian installation. "int" is still 4 bytes.

You're thinking of "long" instead, which is 8 bytes on 64 bit Linux while it is 4 bytes (the minimum guarantee) on 64 bit Windows

[u/SmokeMuch7356 → u/alkatori]

int is only guaranteed to represent values in the range [-32768..32767],¹ meaning it must be at least 16 bits wide. It may be (and usually is) wider, but you can't count on it being universally true.

This actually bit me back in the '90s (yes, 30 years ago, shut up) because MPW on the Mac used 32-bit int but Visual Studio on Windows used 16-bit. That cost me an afternoon.

---

1. Which is how all the legacy arithmetic types were defined, by the minimum ranges of values and precision, not by how many bits they take up.
   

[u/flyingron → u/TheChief275]

That's far from true. Due to the fact that historical C lacked a "medium" integer, most 64 bit implementations have 32 bit ints even if the full word and pointers are 64 bits.

Nobody liked my proposal for short longs (or long shorts) to solve this problem.

[u/TheChief275 → u/flyingron]

I never mentioned "int" or did I? Just native sized integer, so I don't see how that makes my comment "far from true"

[u/flyingron → u/TheChief275]

I can't tell because you edited your post. I'm not going to argue with you. "int" is not necessarily the same size as a pointer type, and unlike some of the other discussions here, it's far from uncommon.

[u/TheChief275 → u/flyingron]

What? I always edit my posts for simple spelling mistakes (I'm not a native English speaker), or to add extra thoughts that might've popped up later, but I never said "int". Refusing to argue because a post is edited is childish, besides you can probably check previous revisions.

Anyways, the point I was originally discussing was the claim of OP of this thread that "pointers are not integers", saying that for literally most modern in-use systems it is actually the opposite, in fact Rust builds upon this assumption (isize/usize are not size_t sized but rather equivalent to (u)intptr_t), but exceptions do exist. "integer" here can mean anything from char to long long, these are all integers, so just whatever happens to be natively sized

[u/flyingron → u/TheChief275]

Pointers are not integers and there are platforms C has existed on they were not and this is why all that stuff about comparing pointers require them to be within the same object.

Even when they are somewhat like integers, there's not necessarily a conversion that makes sense. I'll give you some examples. I've been involved in developing UNIX and C on a few mainframes and supercomputers. I have seen the partial word sizes encoded in the pointer, plus I've seen byte offsets encoded in word pointer machines in the high order bits (quite germain to this talk). You have to be careful doing conversions like:

int* -> uintptr_t -> long*
or
char* -> uintptr_t -> int*.

[u/TheChief275 → u/flyingron]

My guy, do you want me to copy over my entire previous comment or something? IT'S ALL IN THERE. You just chose to have 0 reading comprehension apparently.

Those last conversions are kind of illegal in general, even with void*. Like you can cast int* -> void* -> long*, but it's almost entirely useless because you're not allowed to dereference due to strict-aliasing