|
To close out the discussion on the uses of malloc and calloc
pseudo code
char *zs;
int MEM_WANTED = 0; // can also use #define same results
int unit_size_bytes = 8;
zs = (char*)malloc( MEM_WANTED );
zs = (char*)calloc( MEM_WANTED, unit_size_bytes );
Tests:
zs will not return NULL meaning malloc or calloc has not failed to allocate memory but will return a pointer to an undefined value.
Lesson:
If one uses malloc and/or calloc then one should first test that memory size and unit size (in case of calloc) being requested are not zero, to guarantee the call produces a proper error condition (NULL).
Note:
Tested results using GNU GCC and Visual Studio compilers.
if MEM_WANTED < 0, malloc and calloc return NULL, an expected result
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
jmaida wrote: Lesson:
If one uses malloc and/or calloc then one should first test that memory size and unit size (in case of calloc) being requested are not zero, to guarantee the call produces a proper error condition (NULL).
I disagree. The lesson is that you should read and understand the C standard. Specifically:
Quote: 7.20.3 If the size of the space requested is zero, the behavior is implementation defined: either a null pointer is returned, 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.
Note that returning NULL for malloc(0) still requires you to know what the requested size was. malloc() and friends do return NULL if memory can not be assigned, in which case errno is set to ENOMEM. So if you get NULL back from malloc(), and you don't know the requested memory size, you need to check the value of errno. Furthermore, you also need to know that errno was not ENOMEM before you make the malloc() call, since successful library calls do not modify errno. As I understand it, calling malloc(0) is not an error, so will always succeed and therefore not change the value of errno.
Keep Calm and Carry On
|
|
|
|
|
reading the standard is not the same as the actual performance. BEWARE!
Standards are meant to broken, like rules.
My advise still holds regardless. Protect yourself.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
jmaida wrote: Standards are meant to broken
I'll get a court order to have you not come near my code ever again.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
I would expand the order to include a ban on working in any engineering, engineering-related, or even a profession with agreed Best Practices. I don't want a person with such an attitude in charge of anything that could affect my life.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Not my attitude. The compiler attitude. It's the problem.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
The compiler does exactly what the standard says it should do.
You expecting the compiler to do what YOU want instead of what the standard says is the problem.
|
|
|
|
|
I understand.
I am not expecting compiler to do something it is not programmed to do.
I have bumped into compiler issues for years, especially optimizing features.
Sometimes they change and you have to adapt.
I was just taking issue with the malloc(0) return.
But, I have a way around.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Bruno van Dooren wrote: The compiler does exactly what the standard says it should do.
lol.
Err...no that is not in fact true.
Compilers are written by people. People make mistakes. People have opinions and those can end up impacting how they code something.
That applies to the users also. Even someone who has written compilers might make a mistake in interpreting a specification and then applying that to some code based on a compiler. And most programmers have not written compilers (or at most wrote a toy one in college.)
And on top of that there can be other problems.
1. The 'standard' specification did not in fact go through an actual specification standards process. (Last time I checked the Java Language standard had the exact same bugs that the very first standard did.)
2. Rigorous standards processes allow for reporting problems and ambiguities and they get used. But not all problems are resolved. And without going through (and finding) a lot of that material one is unlikely to know what happened with that.
|
|
|
|
|
I wasn't referring to 'compiler behavior in general across languages' I was referring to the behavior of malloc and calloc which is what this discussions is about. There the compiler does exactly what the standard says it should do.
And while I don't know anything about Java, the C and C++ language specifications are governed by standards committees. C has had a formal standard since 1989. The argument that "in the early days when dinosaurs roamed the land there was no formal standard" is meaningless. It's 2022, there are standards, and whatever C compiler you're using implements one of them.
Different C Standards: The Story of C - open source for you[^]
|
|
|
|
|
Bruno van Dooren wrote: I was referring to the behavior of malloc and calloc which is what this discussions is about. There the compiler does exactly what the standard says it should do.
Ok and which compiler were you referring to? Which version? What was the targeted OS/version for which it would be running?
For example are you absolutely positive that the C compiler for the Raspberry Pi meets every part of the specification?
Following is a list of C compilers - are you sure that every single one of them meets the specification (and addendums) in every way?
List of compilers - Wikipedia[^]
Bruno van Dooren wrote: C has had a formal standard since 1989.
And I was using C both before and after that. There are multiple standards for C. So exactly which standard version are you asserting that one or more of those compilers are compliant with?
|
|
|
|
|
That wasn't the topic of the discussion.
OP was complaining about behavior of their compiler where that behavior was standards compliant.
Which is why I said 'the compiler' because OP's compiler was the subject of this discussion.
Also: It's 2022. We are not talking about the state of compilers in the early 90's. We are talking about today's compilers. Do you know of any modern compiler whose malloc behavior is NOT compliant with a formal C standard?
|
|
|
|
|
Bruno van Dooren wrote: Do you know of any modern compiler whose malloc behavior is NOT compliant with a formal C standard?
You said
"The compiler does exactly what the standard says it should do."
You are asserting an absolute.
I am pointing out, in multiple ways, that as an absolute it is lacking.
|
|
|
|
|
Except it's OP's compiler, which is 'the' compiler we're talking about, in the same way that if we're talking about 'the site' when we're talking about codeproject.com, we're talking about 'this particular site we're talking about, and now every possible website under the sun.
'the compiler' is not an absolute, encompassing all possible compilers in this particular discussion about OP's compiler. The only person satying it was, is you.
|
|
|
|
|
I did read and understand. My recommendation still holds.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
jmaida wrote: if MEM_WANTED < 0, malloc and calloc return NULL, an expected result
Not quite. The signature for malloc is
void *malloc(size_t size); Note that the argument for malloc is a size_t which is an unsigned value. Assuming a 32 bit operating system then malloc(-1) is the same as malloc(4294967295) which you would expect to return NULL and set ENOMEM. However, that's not a guarantee. Consider a 32 bit program running in a 64 bit environment with 64GB RAM. The OS may be able to do some VM magic to honor that request.
Keep Calm and Carry On
|
|
|
|
|
Hopes and prayers are not best practices across the world of programming.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Perhaps.
But the programming world, both compilers and users, are 100% humans so one must accept that nothing is perfect.
|
|
|
|
|
agree. I did human factor simulations for a bit and humans are human.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Totally agree. Humans are great at pattern recognition, but can miss the obvious. I play a computer game called hidden object adventure. It is strange how the obvious is so easily missed.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
to jschell
That is a fact.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
If < zero behaves like zero, according to some then my first warning holds true.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
as to the signed aspect. Yes it may not be interpreted that way, but my malloc and calloc wrappers avoid any confusion.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
on the esp32 platform, size_t is signed. it maps to int.
surprised me too, in a bad way, with compiler warnings.
To err is human. Fortune favors the monsters.
|
|
|
|
|
ouch! that hurts.
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
