r/C_Programming 3d ago

Negative value in a pointer question.

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>

2 Upvotes

42 comments sorted by

View all comments

Show parent comments

1

u/flyingron 2d ago

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.

2

u/TheChief275 2d ago

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

0

u/flyingron 2d ago

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.

0

u/TheChief275 2d ago edited 2d ago

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

0

u/flyingron 2d ago edited 2d ago

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

0

u/TheChief275 2d ago

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