Welcome to the Lounge

12-Dec-22 15:03

C++

char* sz = (char*)malloc(0);

C++

char* sz = strchr("",1);

*hides*

To err is human. Fortune favors the monsters.

Our Forgotten Astronomy | Object Oriented Programming with C++ | Wordle solver

David O'Neil12-Dec-22 15:47

David O'Neil

12-Dec-22 15:47

I wouldn't call either of those C++, even if they are allowed.

Dead | X|

honey the codewitch12-Dec-22 15:50

12-Dec-22 15:50

Technically C, since the latter will give the C++ compiler indigestion due to lack of const qualifier.

There's just not an option for that language here at CP.

That said, these should be syntactically valid, compilable, and comparable functionality-wise.

To err is human. Fortune favors the monsters.

Our Forgotten Astronomy | Object Oriented Programming with C++ | Wordle solver

David O'Neil12-Dec-22 15:58

David O'Neil

12-Dec-22 15:58

honey the codewitch wrote:
That said, these should be syntactically valid, compilable, and comparable functionality-wise.

Yeah, they are C. They are the

Dead | X|

part of C! Laugh | :laugh:

On the other hand:

C++

char * ptr = &something;

Or even just

C++

char * ptr;

This is where I question myself, because isn't it exactly the same? All three of them allocate a char*, even if one of them has a '0' in it? I hated pointers in C because you always had to cast them on both sides, and C++ eliminated that headache for the most part.

jmaida12-Dec-22 16:22

12-Dec-22 16:22

C - equivalent is storage size but not value.
sz is an address with no storage associated with it. it's value is unknown.
sx is an address with a null value.
wrote some code to confirm

"A little time, a little trouble, your better day"
Badfinger

honey the codewitch12-Dec-22 20:33

12-Dec-22 20:33

which compiler? I use GCC and malloc(0) gives me null back (presumably the error condition in this case, like with out of mem)

To err is human. Fortune favors the monsters.

k505413-Dec-22 3:19

k5054

13-Dec-22 3:19

It would actually depend on your libc implementation, not the compiler. Using RedHat Rawhide, I get the following:

Terminal

[k5054@localhost tmp]$ cat example.c 
#include <stdio.h>
#include <stdlib.h>

int main()
{
    char *s = malloc(0);
    printf("s = %p\n", s);
    free(s);
    return 0;
}
[k5054@localhost tmp]$ gcc --version
gcc (GCC) 12.2.1 20221121 (Red Hat 12.2.1-4)
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[k5054@localhost tmp]$ gcc -Wall -Wextra example.c -o example
[k5054@localhost tmp]$ ./example 
s = 0x182f2a0
[k5054@localhost tmp]$

Maybe if you're cross compiling for your controller du jour, its libc is doing that?

Keep Calm and Carry On

honey the codewitch13-Dec-22 4:09

13-Dec-22 4:09

Yeah, I am on a different platform.

To err is human. Fortune favors the monsters.

jmaida13-Dec-22 10:17

13-Dec-22 10:17

I use same and get the same result.

"A little time, a little trouble, your better day"
Badfinger

Daniel Pfeffer13-Dec-22 10:44

Daniel Pfeffer

13-Dec-22 10:44

Don't try malloc(0) at home!

C-2018 7.22.3 states, among other things:
If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned to indicate an error, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object.

IOW this is non-portable code, and should be avoided.

Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.

jmaida13-Dec-22 15:42

13-Dec-22 15:42

int ZERO = 0;
char *sz = (char*)malloc(ZERO);
char *sx = strchr("",1);

printf("Hello world!\n");
printf( "Sizeof char_sz %d bytes value %p\n", (int)sizeof(sz), sz );
printf( "Sizeof char_sx %d bytes value %p\n", (int)sizeof(sx), sx );

Hello world!
Sizeof char_sz 8 bytes value 0000000000ba13f0
Sizeof char_sx 8 bytes value 0000000000000000

Note: value for sz seems to be random which implies it's an address in memory with a value of whatever is in memory at the time. Value of sx is consistently zero or null string.

"A little time, a little trouble, your better day"
Badfinger

Daniel Pfeffer13-Dec-22 22:16

Daniel Pfeffer

13-Dec-22 22:16

The result of malloc(0) is implementation defined. Your compiler apparently allocates a minimal block of memory for each malloc(0), allowing you to call free() on the block. Note that the block may not be portably dereferenced, as its size is 0.

The other option in the C Standard is to return NULL. This also allows free() to be called on the "block", because free(NULL) is specifically allowed in the Standard. The result also cannot be dereferenced (dereferencing NULL is undefined behaviour).

Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.

jmaida14-Dec-22 11:37

14-Dec-22 11:37

I agree. One last test. Using calloc and malloc

I tried both malloc and calloc and got same results.
The calls do not return NULL even if specifying ZERO bytes.
I am using Codeblocks IDE with latest GCC and have C std-17 2017 standard flag set

int ZERO = 0;

char *sz;
char *sx;

printf("Hello world!\n");

sz = (char*)malloc(ZERO);
// sz = (char*)calloc(ZERO, (int)sizeof(sz));
if( sz == NULL ) printf( "returned NULL allocated zero bytes\n");
else printf( "NULL not returned from malloc, allocated 8 bytes\n" );
sx = strchr("",1);

printf( "Sizeof char_sz %d bytes value %p\n", (int)sizeof(sz), sz );
printf( "Sizeof char_sx %d bytes value %p\n", (int)sizeof(sx), sx );
free( sz );
printf( "Sizeof char_sz %d bytes value %p after free\n", (int)sizeof(sz), sz );

Results:

Hello world!
NULL not returned from malloc, allocated 8 bytes
Sizeof char_sz 8 bytes value 0000000000b213f0
Sizeof char_sx 8 bytes value 0000000000000000
Sizeof char_sz 8 bytes value 0000000000b213f0 after free

"A little time, a little trouble, your better day"
Badfinger

Daniel Pfeffer14-Dec-22 11:52

Daniel Pfeffer

14-Dec-22 11:52

Again.

GCC is behaving according to the C Standard, which specifies that malloc(0) or calloc(0, x) return either NULL, or a unique pointer. This is implementation defined behaviour - the implementation must specify what behaviour it supports.

Your code is not checking the size of the block referenced by sz, sizeof(*sz). It is checking the size of the pointer, sizeof(sz). You are apparently running on a system with 64-bit pointers.

If malloc(x) or calloc(y, x) return a non-NULL pointer, you are guaranteed that it points to a memory area of at least x or x * y chars, respectively. In order to discover the exact area, you will need to call an implementation-specific API; the C Standard does not define an API to return the actual size of an allocated memory area.

Note that even if the result of malloc(0) or calloc(0, x) is a unique pointer, that pointer cannot be portably dereferenced, as it is guaranteed to reference only a zero-sized memory area.

Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.

jmaida14-Dec-22 12:08

14-Dec-22 12:08

Understood.
My point is asking for zero bytes of memory gets me an OK (not a NULL) whether I use calloc or malloc.
I have problems with that behavior.
I realize that it's saying I got what I wanted.
Checking for NULL is not a guaranteed successful approach.
Instead one should be checking for non-zero allocation parameters prior to calling malloc or calloc!

"A little time, a little trouble, your better day"
Badfinger

trønderen14-Dec-22 11:55

trønderen

14-Dec-22 11:55

Testing to see what actually happens is a good idea.

But never forget: "Implementation dependent" does not mean "The way gcc implements it" (or any other given compiler), even though gcc users often seems to think that way. Any other C compiler may think differently.

jmaida14-Dec-22 12:10

14-Dec-22 12:10

I agree.

"A little time, a little trouble, your better day"
Badfinger

jmaida15-Dec-22 16:10

15-Dec-22 16:10

The testing showed me that using calloc and malloc requires some extra checking for zero memory requests.
As a result, I am scanning my uses of it in my older code. I do not think I inadvertently allocated zero memory, I want to be sure. BTW malloc and calloc return NULL when memory requested is less than zero.

"A little time, a little trouble, your better day"
Badfinger