|
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
|
|
|
|
|
Weird.
According to the C++ standard (at least it's draft  ): "The type size_t is an implementation-defined unsigned integer type that is large enough to contain the size in bytes of any object".
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
Because the first thing I expect when dealing with C++ is a standards conformant C++ environment. 
But you know what's really fun?
Being confronted with the C++ standard by wise-alecks with google. 
To err is human. Fortune favors the monsters.
|
|
|
|
|
learned this the other day.
To err is human. Fortune favors the monsters.
|
|
|
|
|
You are again confusing the implementation with the Standard. The compiler on my DeathStation 9000 returns a (different) non-NULL pointer for each malloc(0), and is equally compliant as MSVC or GCC, which return NULL.
The Standard defines the argument to malloc() as size_t, which in its turn is defined as an unsigned type that is the result of the sizeof operator. This implies that any negative value cannot be passed to malloc(); any negative argument shall be converted to an equivalent unsigned value.
Section 7.22.3 of the Standard gives the following possible results for a call to malloc(size):
- size > 0 - either the call succeeds (non-null pointer), or it fails (null pointer, errno set)
- size == 0 - [implementation-defined behaviour] either call succeeds (non-null pointer), or it fails (null pointer, errno set)
- size < 0 - non-compliant with the Standard
When a non-NULL pointer is returned, it points to a memory block of at least size characters. There is no exception of the case of size == 0; the memory block is at least of size 0.
The codewitch reports that at least one compiler defines size_t as an a signed value. This is non-compliant with the Standard, and therefore the compiler is arguably not a C compiler.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
