How to determine pointer size preprocessor C

Question

I am working on a software implementation of OpenGL, and OpenGL seems to require that I return 32-bit pointers. To save time, I am putting this into a C equivalent of map with 64-bit systems in order to retrieve 64-bit pointers from 32-bit psuedo-addresses. However, on 32-bit systems, this would cause a hassle, and so I should just use the pointer verbatim.

Here is basically what I want to do in my shared header:

#if <64-bit>
    #include <search.h>
    extern void * pointerTable;
    typedef struct {
          int key;
          void* value;
    } intPtrMap;

    inline int compar(const void *l, const void *r) {
        const intPtrMap *lm = l;
        const intPtrMap *lr = r;
        return lm->key - lr->key;
    }

    inline uint32_t allocate(size) {
        void* result = malloc(size);
        intPtrMap *a = malloc(sizeof(intStrMap));
        a->key = (uint32_t) result;
        a->value = result;
        tsearch(a, &pointerTable, compar);
        return (uint32_t) result;
    }

    inline int getPtr(ptr) {
        intPtrMap *find_a = malloc(sizeof(intPtrMap));
        find_a->key = ptr;
        void *r = tfind(find_a, &root, compar);
        return (*(intPtrMap**)r)->value;
    }
#else
    inline uint32_t allocate(size) {
        return (uint32_t) malloc(size);
    }

    inline uint32_t getPtr(ptr) {
        return (uint32_t) ptr;
    }
#endif

Any suggestions on how to do the first if?

How about using a plain `if` and seeing if the optimizer is clever enough to remove dead code? I'd expect it to be. — Quentin, Jul 31 '18 at 14:48
`a->key = (uint32_t) result;` is likely not unique. Malloc could even return `(uint32_t) result == 0` every time and be perfectly standard conform. — Goswin von Brederlow, Jul 31 '18 at 14:53
Under Linux how about simply using 32bit addresses? mmap() has a flag `MAP_32BIT` to allocate memory in the first 2GB of address space. Or use `MAP_FIXED` with a low enough address. Both would ensure the upper 32bits of any pointer are 0 bits and you can use them without having to map them. — Goswin von Brederlow, Jul 31 '18 at 14:56
Aside: To avoid `int` overflow with `lm->key - lr->key;` and _undefined behavior_, use `(lm->key > lr->key) - (lm->key < lr->key);` — chux - Reinstate Monica, Jul 31 '18 at 15:03
Instead of `#if <64-bit>`, perhaps `#if UINTPTR_MAX > 0xFFFFFFFF`? — chux - Reinstate Monica, Jul 31 '18 at 15:06
`intPtrMap a = malloc(sizeof(intStrMap));` is certainly invalid code. What is code, @Lightning Creations, trying to do here? — chux - Reinstate Monica, Jul 31 '18 at 15:09
@Quentin I came up with a solution. I prefer to use preprocessor in the case of newer compilers with worse optimizers, such as one that is being made for the SNES that is going to be able to run this. — Lightning Creations, Jul 31 '18 at 15:11
@GoswinvonBrederlow 1. There is under a 1/1000000 chance of collision for each new allocation. I worked it out. — Lightning Creations, Jul 31 '18 at 15:12
@GoswinvonBrederlow 2. This is made to be cross platform, not just Linux-based. — Lightning Creations, Jul 31 '18 at 15:13
The bad old days use configure scripts that compile code using `printf("%d\n, sizeof(void*))` to define a `POINTER_SIZE` variable for the preprocessor. *shiver*. — Goswin von Brederlow, Jul 31 '18 at 15:20
Are you sure OpenGL uses 32-bit pointers and not 32-bit IDs? Have you seen [this answer](https://stackoverflow.com/a/24694186/5264491) to [this question](https://stackoverflow.com/q/24690014/5264491)? — Ian Abbott, Jul 31 '18 at 15:24
@IanAbbott I would use IDs, but just using memory addresses seems to be easier since I'm not actually using the graphics card at all for this. — Lightning Creations, Jul 31 '18 at 15:49
The code does not smell right. Are you sure this is needed? You do not have types for your parameters. — William J Bagshaw, Jul 31 '18 at 16:02

chux - Reinstate Monica · Accepted Answer · 2021-03-13T14:19:28.857

How to determine pointer size preprocessor C (?)

To determine pointer size in a portable fashion is tricky.

Various pointers sizes

It is not uncommon to have a pointer to a function wider than a pointer to an object or void*.
Pointers to int char, struct can be of different sizes, although that is rare.
So let us reduce the task to determine void * pointer size.

Pre-processor math

PP math is limited, so code needs to be careful. Let us stay with integer math.

(u)intptr_t

The optional types (u)intptr_t, which are very commonly available, are useful here. They allow conversion of a void * to an integer and then to an equivalent void*.

Although the integer type size may differ from the pointer type, that, I assert is rare and detectable with _Static_assert from C11.

Following will handle many C11 platforms. Useful ideas toward a general solution.

#include <stdint.h>

// C11
_Static_assert(sizeof (void*) == sizeof (uintptr_t), 
    "TBD code needed to determine pointer size");

// C99 or later
#if UINTPTR_MAX == 0xFFFF
  #define PTR16
#elif UINTPTR_MAX == 0xFFFFFFFF
  #define PTR32
#elif UINTPTR_MAX == 0xFFFFFFFFFFFFFFFFu
  #define PTR64
#else
  #error TBD pointer size
#endif

[Edit 2021]

With Is there any way to compute the width of an integer type at compile-time?, code could use, at compile time, the below to find the width of uintptr_t.

/* Number of bits in inttype_MAX, or in any (1<<k)-1 where 0 <= k < 2040 */
#define IMAX_BITS(m) ((m)/((m)%255+1) / 255%255*8 + 7-86/((m)%255+12))
#define UINTPTR_MAX_BITWIDTH IMAX_BITS(UINTPTR_MAX)

"`It is not uncommon to have a pointer to a function wider than a pointer to an object or `void*`.`" -- It's certainly permitted by the C standard, but in my experience it is quite uncommon. — Keith Thompson, Jul 31 '18 at 16:06
[Why are function pointers and data pointers incompatible in C/C++?](https://stackoverflow.com/q/12358843/2410359) goes into issues including size. — chux - Reinstate Monica, Jul 31 '18 at 16:23
Yes, I understand the issues. My point is merely that on most modern systems, all pointers are the same size. — Keith Thompson, Jul 31 '18 at 20:46

Lightning Creations · Answer 2 · 2018-07-31T15:16:49.163

1

Using other questions on StackOverflow and also a solution from somebody on Discord, I have cobbled together this solution:

#if _WIN32 || _WIN64
    #if _WIN64
        #define PTR64
    #else
        #define PTR32
    #endif
#elif __GNUC__
    #if __x86_64__ || __ppc64__
        #define PTR64
    #else
        #define PTR32
    #endif
#elif UINTPTR_MAX > UINT_MAX
    #define PTR64
#else
    #define PTR32
#endif

This should be able to reliably determine 64-bit or 32-bit pointer usage in preprocessor.

edited Jul 31 '18 at 15:16

answered Jul 31 '18 at 15:10

Lightning Creations

127
1
11

3

You can't use `sizeof` in a preprocessor expression. – Ian Abbott Jul 31 '18 at 15:14
It compiles fine, but since I have seen better things in other comments, I will replace it. – Lightning Creations Jul 31 '18 at 15:15
Good idea! Putting that in now. – Lightning Creations Jul 31 '18 at 15:17
1

Actually, your `UINTPTR_MAX > 0xFFFFFFFF` was more explicit than my `UINTPTR_MAX > UINT_MAX` suggestion. (Sorry I deleted my comment earlier.) – Ian Abbott Jul 31 '18 at 15:20
But I'm really comparing it to the UINT max for storage, so this is better. – Lightning Creations Jul 31 '18 at 15:49
`UINTPTR_MAX > UINT_MAX` --> The goal is not then to determine if the pointer is 64-bit, but if it wider than `unsigned`. – chux - Reinstate Monica Jul 31 '18 at 15:55
And since uint32_t (uint) is 32-bit, bigger would be 64-bit. – Lightning Creations Jul 31 '18 at 16:01
This code is a whole lot of wishful thinking. The real world is not so kind. – tadman Jul 31 '18 at 16:19
@LightningCreations `uint32_t (uint)` is unclear. Also note that `UINT_MAX` may be as small as 0xFFFF as used in `UINTPTR_MAX > UINT_MAX`. – chux - Reinstate Monica Jul 31 '18 at 16:19
In that case, I would need to act as if the pointer were 32-bit anyway, since truncation would kill my system. – Lightning Creations Jul 31 '18 at 16:30

How to determine pointer size preprocessor C

2 Answers2