Okay to use sizeof(void*) when allocating a new pointer to a string?

[synthetix]

I have a pointer-pointer variable that contains strings of characters. It is dynamically added to when more data becomes available. I must first allocate the pointer to each string, and then allocate the actual string:

char **phrases = NULL;

char temp[] = "Hi there!";

phrases = malloc(sizeof(*phrases));
phrases[0] = malloc(sizeof(temp)+1);
strcpy(phrases[0],temp);

The thing is, since I know the pointer to the string will always be 4 or 8 (depending on the machine architecture), can't I just use sizeof(void*)? sizeof(void*) should return 4 or 8, depending on whether I compiled 32 or 64 bit.

[iMalc]

As per line 5, you clearly know the best way to do it, so why would you ask about any not-as-good way of doing it?

[synthetix]

As per line 5, you clearly know the best way to do it, so why would you ask about any not-as-good way of doing it?

Well, the question wasn't really about which way is "better" or not. I'm more concerned about whether there will be any problems doing it the other way, that is using a generic void*.

Why do you think using void* isn't as good? Not trying to be combative, just genuinely curious.

[whiteflags]

Why do you think using void* isn't as good? Not trying to be combative, just genuinely curious.

Pointers don't have to be the same size, even though data pointers are usually 4 bytes wide today. Most if not all of the things that you allocate will be data-related, but still. Ever hear the phrase, assumptions make an ass out of you and me? That's basically what's going on here.

For the final authority, nothing better than the standard, though.

A pointer to void shall have the same representation and alignment requirements as a pointer to a character type. Similarly, pointers to qualified or unqualified versions of compatible types shall have the same representation and alignment requirements.28) All pointers to structure types shall have the same representation and alignment requirements as each other. All pointers to union types shall have the same representation and alignment requirements as each other. Pointers to other types need not have the same representation or alignment requirements.

[iMalc]

Well, the question wasn't really about which way is "better" or not. I'm more concerned about whether there will be any problems doing it the other way, that is using a generic void*.

It's not impossible that doing it "the other way" could cause problems, but as you already know how to do what will always work, there's probably no point in asking.
If you're really "just curious" then track down and read a copy of the standard.
If there's the slightest hint that you might consider writing code that way then that would be a waste.

[grumpy]

Well, the standard does not guarantee that a void * is the same size as a char * (having the "same representation and alignment requirements" as per the clause whiteflags quoted doesn't necessarily mean "identical representation"). In practice, since any pointer must survive a round-trip conversion (X * -> void * and back) a sizeof(void *) will normally be at least the size of any other pointer. That doesn't exclude a void * being larger than another pointer type. Which makes allocating a memory for a void * when you actually need memory for a char * unnecessarily wasteful - it may allocate more memory than needed.

That said, I have yet to come across any report or documentation of a compiler that supports a void * that is of different size than a char *. There is also no guarantee that pointers have any particular sizes.

In the end, however, I agree with iMalc's point. Code is easier to understand, and therefore easier to get right, if it explicitly does what is intended. In this case, you intend to allocate a char *. Using malloc(sizeof(void *)) may do nothing different, technically. But in your code, it obfuscates the meaning without any benefit. Code with obfuscated meaning is code that can trick a programmer (including yourself at some future date) into believing the code does something different than it actually does, and therefore introduce subtle bugs.

Incidentally, your code (even without changing it to work with allocate sizeof(void *)) has two potentially serious bugs.

Firstly, it does not check that phrases is non-NULL before allocating memory to phrases[0]. It should.

Second, the allocation of phrases[0] = malloc(sizeof(temp)+1); is flawed in several ways. sizeof(temp) will be the length of temp + 1 (i.e. sizeof(temp) catches the terminating zero byte in temp). Your code is therefore allocating more memory than needed. Your code will also break miserably if the code is ever restructured so temp is a pointer. For example, if your code is changed to this

char **phrases = NULL;
 
char *temp = "Hi there!";
 
phrases = malloc(sizeof(*phrases));
phrases[0] = malloc(sizeof(temp)+1);    /*   Should check that phrases is non-NULL first */
strcpy(phrases[0],temp);

Then sizeof(temp) will be the size of a pointer to char, not the size of the string. If sizeof(temp) < strlen(temp) ever occur, which it can and probably will, then the strcpy() call yields undefined behaviour.

[synthetix]

Using malloc(sizeof(void *)) may do nothing different, technically. But in your code, it obfuscates the meaning without any benefit. Code with obfuscated meaning is code that can trick a programmer (including yourself at some future date) into believing the code does something different than it actually does, and therefore introduce subtle bugs.

Thanks. That's a valid point and I certainly agree.

Firstly, it does not check that phrases is non-NULL before allocating memory to phrases[0]. It should.

Ah. Good call. I will definitely do that.

Second, the allocation of phrases[0] = malloc(sizeof(temp)+1); is flawed in several ways. sizeof(temp) will be the length of temp + 1 (i.e. sizeof(temp) catches the terminating zero byte in temp). Your code is therefore allocating more memory than needed.

Actually, the code I posted was wrong. That line should have used strlen() instead of sizeof():

phrases[0] = malloc(strlen(temp)+1);

The extra char was added to malloc() to account for the terminating character, which is not taken into account by strlen().

[grumpy]

Actually, the code I posted was wrong. That line should have used strlen() instead of sizeof():

You're more-or-less confirmed my point.

While it is a good form to keep code you post to forums small (which you did) it is really poor form to post code that differs from your actual code. Otherwise, you just waste people's time and effort.