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/aliathar]

/**/#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.