tags:

views:

336

answers:

3

Can we change the size of size_t in C?

+8  A: 

No. But why would you even want to do it?

AndreyT
i want to locate where size_t macro is and see how it is implemented
tsubasa
@tsubasa: Then that is a different question entirely.
ThisSuitIsBlackNot
It's probably a typedef rather than a macro.
martin clayton
`size_t` is a typedef-name, not a macro.
AndreyT
+4  A: 

size_t is not a macro. It is a typedef for a suitable unsigned integer type.

size_t is defined in <stddef.h> (and other headers).

It probably is typedef unsigned long long size_t; and you really should not even think about changing it. The Standard Library uses it as defined by the Standard Library. If you change it, as you cannot change the Standard Library, you'll get all kinds of errors because your program uses a different size for size_t than the Standard Library. You can no longer call malloc(), strncpy(), snprintf(), ...

pmg
It's probably either `unsigned int`, `unsigned long`, or `unsigned long long`, depending on the maximum object size supported by the compiler.
Loadmaster
thanks this is what i'm loooking for
tsubasa
A: 

If you want to fork Linux or NetBSD, then "Yes"

Although you can redefine macros this one is probably a typedef.

If you are defining an environment then it's perfectly reasonable to specify size_t as you like. You will then be responsible for all the C99 standard functions for which conforming code expects size_t.

So, it depends on your situation. If you are developing an application for an existing platform, then the answer is no.

But if you are defining an original environment with one or more compilers, then the answer is yes, but you have your work cut out for you. You will need an implementation of all the library routines with an API element of size_t which can be compiled with the rest of your code with the new size_t typedef. So, if you fork NetBSD or Linux, perhaps for an embedded system, then go for it. Otherwise, you may well find it "not worth the effort".

DigitalRoss