OSDev.org

To my knowledge, (in C) the sizeof operator will return a size_t value.
But what happens if I use a custom typedef for size_t, or if I #define it as a macro?

Will the compiler automagically use my own type for the sizeof operator?

The sizeof will return the original size_t type since keywords are wired logic they don't affect by programmer's code.

A simple experiment show the proof: gcc gives warning: format ‘%d’ expects type ‘int’, but argument 3 has type ‘long unsigned int’
This suggest sizeof is unaffected by my typedef and is still 64-bit.

However, as soon as you cast the sizeof returned value to your own size_t you doing a casting there.

Bottom line, by redefining size_t you are going to shoot your own feet, and the compiler may or may not warn you for type conflict.
Anyway, don't do it. You should always use <stdint.h>

... but I am using stdint.h. My own. That's where my dilemma arose from.

Edit: I'm sorry if I posted in the wrong subforum, in which case please move this thread.

Actually, this is a good way to check if your compiler and your library agree on the size of size_t.

You either have to adapt your library to your compiler, or configure the compiler so that it uses your desired size for your platform. Unless you really really really know what you're doing, I recommend the former.

Compiling with -nostdinc -nostdlib -m32, and linking with -nostdlib, the size of size_t is fixed at 32 bits, disobeying my typedef.
I'm not surprised that the operator spits out a 32-bit int, but then why does size_t act as if it's a builtin type, when it isn't?

I'd like to pursue your latter suggestion Solar, if possible. Have you anything to add to it?

Well, size_t is something where the compiler and the library have to meet halfway. sizeof() is an operator, i.e. the return type is hardcoded into the compiler - which doesn't know anything about what you wrote in your library headers. But in order to handle the type correctly, the library must declare it to be whatever the compiler uses.

(And that's most likely unsigned long, not int.)

As for changing the type... that's part of what I meant when I said, "only do this if you really know what you're doing". You would have to create a new config for a new compiler target. That's a somewhat involved operation, and chances are that you want to achieve the wrong thing.

Let me put it differently: What makes you think that the compiler's choice for the type of size_t is wrong?

If you really want to do this, check out "GCC Internals", section "Machine Description" - but don't expect any help from me or say that I didn't warn you.

Solar wrote:What makes you think that the compiler's choice for the type of size_t is wrong?

Good point. I'll backpedal this time. At least I'm no longer confused, so thanks.

Hobbes... that's nice. But I don't think it comes with similar macros for size_t's limits, to be put in limits.h?

Civillian wrote:Hobbes... that's nice. But I don't think it comes with similar macros for size_t's limits, to be put in limits.h?

Not in a compiler-independent way, no.

But if you are targeting GCC specifically, be informed that it already provides all headers from the freestanding environment on its own, including <stdint.h>, <limits.h>, <float.h> etc.

This can demonstrate the problem if you redefine the size_t to something smaller than the internal Note that gcc may not give you overflow warning if the size somehow fits into size_t a, however this will bite you later when you expand the size of foo later.

@ Hobbes:

You are aware that size_t is an unsigned type?

I guess I didn't search hard enough, thanks Hobbes.
The true goldmine is here: http://gcc.gnu.org/onlinedocs/cpp/Commo ... acros.html

Solar wrote:But if you are targeting GCC specifically, be informed that it already provides all headers from the freestanding environment on its own, including <stdint.h>, <limits.h>, <float.h> etc.

What exactly do you mean by this? I already have custom versions of the first two.

Look into ${PREFIX}/lib/gcc/${TARGET}/${VERSION}/include. Since the freestanding environmen does not include any executable code, but only definitions and macros depending on the compiler / target machine anyway, GCC provides these "for free".

Solar wrote:@ Hobbes:

You are aware that size_t is an unsigned type?

Dang! Don't know what hit me when I wrote that

Civillian, you're welcome.