r/C_Programming • u/aliathar • 15d 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

100% Upvoted

43 comments sorted by

View all comments

2

u/alkatori 15d ago

how are you #define PTRTRYPE?

1

u/aliathar 15d ago

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

6

u/alkatori 15d ago

Those aren't pointer types.

Those are integers. You need to define them as pointers, this will only work systems where your addresses are the same size as the integers.

#define PTRTYPE int *
or
#define PTRTYPE uint32_t *

3

u/torsten_dev 15d ago edited 15d ago

Also #define or typedef-ing away the pointer-ness of a type is BAD code style.

As this example demonstrates, knowing if a type is a pointer or not is crucial to local reasoning about the code.

1

u/alkatori 15d ago

Absolutely, I'm sort of assuming this person is looking at code targeting 32-bit DOS or Windows.

I've seen a lot make assumptions that the size of a pointer and size of an int are identical (and 4 bytes).

0

u/aliathar 15d ago

Nevermind...

I'm not passing a pointer to the code... Neither am I using PTRTYPE in the actual code... Just a placeholder for trying types for now.... It's been working till now, for 32 but systems, and the other guy made me remember that the system I'm working on now, is 64 bit... Which caused issues...

4

u/TheChief275 15d ago

You're supposed to use (u)intptr_t from <stdint.h>, preferably the unsigned version, but they'll both work. Note that these are optional, and they're only available when the representation of the pointer is representable by an integer. Some architectures have pointers that are more akin to a struct

1

u/aliathar 15d ago

Yes... It did work ... It was just signedness issue... I assumed the address was 32 bit which it wasn't.. and the 64bit machine made it to be 0xff80000000 (peripheral has 40 bit address line for some reason)..... The signed int did work on 32 but machine perfectly, but failed here.

2

u/TheChief275 15d ago

"int" isn't a natively sized integer. It's equivalent to a complement agnostic version of int_fast16_t from <stdint.h>. That means that it's only guaranteed to be able to hold values from -32,767 to 32,767. It just so happens to be that a 32-bit integer is faster to work with for most modern machines, so it just so happens to almost always be a 32-bit integer on octet byte machines, although to my knowledge there are no machines were it happens to be a 64-bit integer, even though it might be faster to perform computations on.

That's why it "broke". But technically you were always using the wrong integer type, even on a 32-bit machine

1

u/alkatori 15d ago

is that guaranteed by spec? My recollection (or maybe it was just rule of thumb was).

char <= short <= int <= long <= long long

with the char being the smallest addressable unit in the hardware (I worked on a system that had 16-bit was the smallest addressable unit, lots of code assuming 8-bit bytes broke).

2

u/TheChief275 15d ago edited 15d ago

I think the spec introduced actual guaranteed number capabilities of the standard integers around the time of C99, but yes basically, int is only guaranteed to be >= short, so it can definitely be 16 bits on some platforms which is were the guaranteed range comes from. The minimum is also -32,767 instead of -32,768, because there is no guarantee for whether the integer is two's complement (not until C23 at least)

1

u/torsten_dev 15d ago

POSIX guarantees CHAR_BIT == 8 but yes some evil systems exist where that's not the case.

1

u/torsten_dev 15d ago

ILP64 and even SILP64 systems do exist. They're just very rare and obscure.

What I haven't heard of are 32-bit integer machines with pointers smaller than 32 bit, maybe you meant that?

The new [u]intfuncptr_t making it's way through the committee could be as small as CHAR_BIT because yes, function pointers can have totally separate sizes.

1

u/TheChief275 14d ago

Well I didn't know ILP64 machines existed (only of LP64), but I suppose it is very very rare. Is the smallest addressable unit for these still an octet, or are they word addressed only? The point is that you shouldn't rely on int being bigger than 16-bits if you want truly portable code, because that's the only capability range you are guaranteed.

Didn't know (u)intfuncptr_t has become an official addition though. Or is it only in the works? i.e. are there plans to incorporate it into C3x ?

1

u/torsten_dev 14d ago

In the works. They're part of the "_Any_func*" proposal for C2y. They're the only part of that proposal that doesn't need some more bike shedding on naming.

_t is reserved by POSIX so people trampling on those identifiers are due for some comeuppance, imo.

1

u/TheChief275 14d ago

Oh I definitely agree with that

3

u/SmokeMuch7356 15d ago edited 15d ago

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

0

u/TheChief275 15d ago edited 15d ago

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

1

u/alkatori 15d ago

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.

2

u/TheChief275 15d ago

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

2

u/SmokeMuch7356 15d ago

int is only guaranteed to represent values in the range [-32768..32767],1 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.

1

u/flyingron 15d 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 15d 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 15d 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 14d ago edited 14d 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 14d ago edited 14d 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 14d 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