0

What is the size of a char*, or how would I be able to get the size of it? Would it simply be

sizeof(char)

or

sizeof(char[])

I am asking this because I am trying to make a data structure (a queue) that holds char* as its data type and for the initialization/creation of the queue, I need to pass in the size of the data type as a parameter. If it were an integer:

queue* q = createQueue(sizeof(int))

How would I do something like this for a char*? Would something like this work or do I have the wrong idea? Do I need to use char**, but then I believe that the implementation of the queue would need to change since I am following a generic queue implementation I found on GitHub.

GSerg
  • 76,472
  • 17
  • 159
  • 346
SteamedBun
  • 91
  • 9
  • 11
    Have you tried `sizeof(char*)`?.. – GSerg Jul 13 '21 at 23:49
  • Would having a sizeof(pointer) be valid? Tbh I just thought that didn't work so I kind of just ruled it out. But if it is valid then I guess that's it? – SteamedBun Jul 13 '21 at 23:53
  • 2
    If you want to know the size of `char*`, which is what you seem to be asking about, then what else is the answer other than `sizeof(char*)`? Or do you want to know the [length of the string](https://stackoverflow.com/q/15000544/11683) pointed to by a `char*`, which is a different thing? – GSerg Jul 13 '21 at 23:55
  • 1
    Yes, using `sizeof` to determine the size of a pointer is valid, so `sizeof(char *)` is what you want. – user3386109 Jul 13 '21 at 23:57
  • 1
    Re "*Would having a sizeof(pointer) be valid?*", Well, `pointer` has no intrinsic meaning in C, but if it's a placeholder for a pointer type, it's most definitely valid. It would be a bit odd to allocate just a pointer, but what about an array of pointers? That's actually pretty common. And you'd need to know the size of a pointer to do that. – ikegami Jul 14 '21 at 00:10
  • @SteamedBun It is unclear what you are trying to do. – Vlad from Moscow Jul 14 '21 at 01:45

4 Answers4

2

char* is a pointer, thus has the same size than any other pointer (int*, void*...). On 64-bit CPU, pointer size is 8-bytes.

You can simply write sizeof(char*)

https://onlinegdb.com/ySTtpNFSg

VRichardJP
  • 160
  • 9
  • 6
    Re "*thus has the same size than any other pointer*", I don't believe this is guaranteed. But it is on an x86/x64. – ikegami Jul 14 '21 at 00:05
  • 6
    Re "*On 64-bit CPU, pointer size is 8-bytes.*", I don't believe this is guaranteed either. – ikegami Jul 14 '21 at 00:06
  • @ikegami, I'm curious. Do you have a counter-example? – VRichardJP Jul 14 '21 at 00:44
  • 3
    It is quite clear the C standard does not require pointers of different types to be the same size, regardless of whether anybody presents examples here, with limited exceptions listed in C 2018 6.2.5 28, which says pointers to `void` and character types shall have the same representation, pointers to qualified or unqualified versions of compatible types shall have the same representation, all pointers to structure types shall have the same representation, and all pointers to union types shall have the same representation… – Eric Postpischil Jul 14 '21 at 02:19
  • … Then it says “Pointers to other types need not have the same representation or alignment requirements.” – Eric Postpischil Jul 14 '21 at 02:19
  • 1
    Further, the size of a pointer is determined by the C implementation, not the CPU. I have worked with a C implementation that had 32-bit pointers on a 64-bit CPU. This answer is correct that `sizeof (char *)` produces the size of a pointer to `char` and wrong in its other statements about it. – Eric Postpischil Jul 14 '21 at 02:20
  • Everything @EricPostpischil says is true, but it's worth pointing out that both POSIX and Windows implicitly require all pointers to have the same representation (including both object and function pointers); the `dlsym`/`GetProcAddress` interfaces would not be usable as intended otherwise. I thought POSIX made this explicit somewhere but I'm not having any luck finding it. – zwol Jul 14 '21 at 13:03
  • @zwol: `dlsym` returns a `void *`, and `GetProcAddress` returns a `FARPROC`. For them to be usable as intended, it is merely necessary these be convertible to pointers to the things they are intended to point to, not that the pointers have the same representation. – Eric Postpischil Jul 14 '21 at 13:11
  • @EricPostpischil It's more subtle than that, but I can't remember anymore what the issue was, only that this was why the original ABI for the Cray (in which `void *` and `char *` were bigger than all the other pointer types) had to be abandoned. – zwol Jul 14 '21 at 13:14
1

There’s nothing magic about pointer types - a pointer has a size like any other object type1, so it’s just as valid to use sizeof (char *) as sizeof (char).

Pointer type sizes are as big as the implementation needs them to be, and different pointer types may have different sizes2. Similarly, the internal representation of pointer types can vary among implementations.

Remember that sizeof is an operator, not a function; parens are only required if the operand is a type name. Also, unless its operand is a variable-length array, sizeof expressions are evaluated at compile time, not runtime. Similarly, sizeof only cares about the type of its operand, not its value or how it’s stored. You can use sizeof on expressions as well as type names - a common idiom for malloc is

T *p = malloc( N * sizeof *p ); // for any type T

The expression *p has type T, so sizeof *p == sizeof (T).


  1. void is an incomplete type that cannot be completed - you cannot create an object of void type and strictly speaking the type has no size. You can, however, create an object of void * type, and its size and alignment will be the same as char *. A void * is a "generic" pointer type and can be converted to other pointer types without an explicit cast. Since there's no such thing as a void object, you cannot dereference a void * - you have to convert it to another pointer type first.
  2. On common platforms like x86 all pointer types have the same size, but that’s not required.
John Bode
  • 119,563
  • 19
  • 122
  • 198
0

As mentioned in other comments, the char* is a pointer, so it is a number referencing the memory position where the actual char is. I would like to add that the actual size may depend on the architecture of the computer as mentioned here.

For further reference about size of types see this link of the cppreference website.

-1

sizeof(char*) returns the size of a pointer.

If you're compiling for the x86, it's virtually guaranteed to be 4 bytes.
If you're compiling for the x64, it's virtually guaranteed to be 8 bytes.

Yes, it's perfectly valid to get the size of a pointer. While it would be a bit odd to allocate a single pointer dynamically, it's quite common to allocate an array of them. For example, say you have wanted to genericize your queue. The first thing you'd do is make it a queue of pointers.

typedef struct {
   size_t capacity;
   size_t count;
   void **array;
   // ...
} Queue;

int Queue_init(Queue *q) {
   q->capacity = 10;
   q->array = malloc(sizeof(void*) * q->capacity);
   if (!q->array)
      return 0;

   q->count = 0;
   // ...

   return 1;
}
ikegami
  • 367,544
  • 15
  • 269
  • 518
  • In spite of the caveat, “If you're compiling for the x64, it's virtually guaranteed to be 8 bytes.” is not a good thing to tell people. I have worked with a C implementation that had 32-bit pointers on a 64-bit CPU. (It was configured that way to save space—and consequentially time and energy—in pointer-heavy code.) Code written in expectation of a virtual guarantee would break. Just use the actual size of a `char *`, not a presumed size. – Eric Postpischil Jul 14 '21 at 02:22
  • @EricPostpischil 1. I did not say "on a 64-bit CPU" 2. The question was literally what size it is. The suggestion not to answer the question has been declined. – ikegami Jul 14 '21 at 03:47
  • My comment neither says you said “on a 64-bit CPU” nor that you should not answer the question. – Eric Postpischil Jul 14 '21 at 10:27
  • In spite of the caveat, “If you're compiling for the x64, it's virtually guaranteed to be 8 bytes.” is not a good thing to tell people. This leads people to build assumptions into their code, which is bad engineering. As my example shows, there are reasons for C implementations not to have 64-bit pointers on 64-bit CPUs. The answer would be improved by removing the statement. – Eric Postpischil Jul 14 '21 at 15:34
  • @EricPostpischil But that was the question asked. And you just said I should answer the question – ikegami Jul 14 '21 at 15:35
  • No, the question asked is “What is the size of a `char *`?”, not “What is a virtual guarantee about the size of a `char *`?” – Eric Postpischil Jul 14 '21 at 15:59
  • @EricPostpischi wait. Now you're complaining I didn't say it was always 8 bytes?! I didn't say that cause it would have been wrong. – ikegami Jul 14 '21 at 16:02
  • One correct answer is “`sizeof (char *)` evaluates to the size of a `char *`.” (Also that it evaluates to the size; it does not “return” the size.) A partial answer is that “The size of a `char *` in most x86 C implementations is four bytes, and the size of a `char *` in most x64 C implementations is eight bytes, but you should not rely on these without using `sizeof` or another method to verify it.” An assertion that the size is “virtually guaranteed” might be technically correct in some sense, but not in others, and is bad advice regardless. It is unnecessary and bad engineering. – Eric Postpischil Jul 14 '21 at 16:05
  • @EricPostpischil and the second thing you said is exactly what I said in my answer – ikegami Jul 14 '21 at 16:08
  • Telling somebody that `sizeof (char *)` evaluate to the size of a `char *` is not saying the derivative of x^2 is the derivative of x^2 or saying the size of a `char *` is the size of a `char *`. It is giving them a method to obtain the size in source code, and, for this OP who thought you could not use `sizeof (char *)` for some reason, it tells them they can. – Eric Postpischil Jul 14 '21 at 16:09
  • What is `size`, – Mustafa Aydın Jul 17 '21 at 09:55
  • @MustafaAydın typo, fixed – ikegami Jul 17 '21 at 14:15