call to malloc with size 0

[Keith Thompson]

Nonsense!

No, it's not nonsense, as we've repeatedly explained at length.

Lots of people who post here have good rerasons
to cast the pointer returned by the malloc(size_t).

You claim to have a good reason, with no real justification that I've
seen. P.J. Plauger apparently does have a good reason; he needs to
write code that his customers can compile either as C or as C++. I
haven't seen anyone else make a coherent argument in favor of casting
the result of malloc().

[...]

Write:

char* p = (char*)malloc(n*sizeof(char*));

and both C and C++ compilers will accept your code.

Write

char *p = malloc(n);

or

some_type *p = malloc(n * sizeof *p);

and use a C compiler. Or use a "new" operator and use a C++ compiler.

 

[Herbert Rosenau]

Write:

char* p = (char*)malloc(n*sizeof(char*));

and both C and C++ compilers will accept your code.

Twitsdale is posting crap once again. Twitsdale is unable to learn C
as defined by the standard because he thinks ther is no other C
compiler as Wincrap existent on the real world.

Put twitsdale into your filters and you bewares yourself always of the
crap this bloody ignorant craps out of his ass.

There is really NO, absolutely NO reason to cast the result of a
function that returns a pointer to void. But here are thousend reasons
you invoke the lands of undefined behvior. When you writs C++ you have
in no ways a reason to use malloc() - new will always be better. When
you have to write C - use a C-compiler, when you have to write C++
then you have to use a C++-comiler.

 

[Herbert Rosenau]

Dereferencing the result of malloc(0) yields undefined behavior.

No, implementation defined behavior only.

What problem do you envision with type-casting it?

undefined behavior as always by casting a result of a function that
returns pointer to void and is called without prototype in sight.
Implemenation defined behavior can be tolerable - undefined behavior
is never.

 

[Ben Pfaff]

No, implementation defined behavior only.

Here is what the standard says:

If an invalid value has been assigned to the pointer, the
behavior of the unary * operator is undefined.83)

If malloc(0) returns a null pointer, then this is sufficient to
makes its behavior undefined. If malloc(0) return a non-null
pointer, then this quote from the standard holds:

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.

A violation of a "shall" requirement yields undefined behavior:

If a ``shall'' or ``shall not'' requirement that appears
outside of a constraint is violated, the behavior is
undefined.

Why do you think that dereferencing malloc(0) yields only
implementation-defined behavior?

undefined behavior as always by casting a result of a function that
returns pointer to void and is called without prototype in sight.

I don't see how this is specific to malloc(0), and I don't see
that this is the issue at hand anyhow.

Implemenation defined behavior can be tolerable - undefined
behavior is never.

Only in programs intended to be completely portable.

 

[Joona I Palaste]

On Fri, 19 Nov 2004 23:26:05 UTC, "E. Robert Tisdale"

Twitsdale is posting crap once again. Twitsdale is unable to learn C
as defined by the standard because he thinks ther is no other C
compiler as Wincrap existent on the real world.

Put twitsdale into your filters and you bewares yourself always of the
crap this bloody ignorant craps out of his ass.

There is really NO, absolutely NO reason to cast the result of a
function that returns a pointer to void. But here are thousend reasons
you invoke the lands of undefined behvior. When you writs C++ you have
in no ways a reason to use malloc() - new will always be better. When
you have to write C - use a C-compiler, when you have to write C++
then you have to use a C++-comiler.

Furthermore, Trollsdale used the wrong type in his sizeof operation.
The correct type would be what the pointer points at, not the pointer
type itself. sizeof *p would have worked much better.

 

[Spiro Trikaliotis]

Hello,

When you writs C++ you have in no ways a reason to use malloc() - new
will always be better.

If I want to implement my own operator new, there are legit reasons to
call malloc on my own, even in C++.

But this is getting OT in this newsgroup here.

Regards,
Spiro.

 

[Mark McIntyre]

No, implementation defined behavior only.

The return from malloc is implementation defined but must be either a null
pointer or an unusable pointer. Dereferencing either of those is undefined,
by definition....

 

[Mark McIntyre]

Hello,



If I want to implement my own operator new,

But this isn't writing in C++, this is writing a compiler...

there are legit reasons to
call malloc on my own, even in C++.

If you want to implement your own operator new, you'd be better advised to
use processor-specific memory management primitives.

But this is getting OT in this newsgroup here.

indeed.

 

[Charlie Gordon]

Write:

char* p = (char*)malloc(n*sizeof(char*));

and both C and C++ compilers will accept your code.

Right : neither will catch that you don't get the difference between char and
char* !

A compromise solution :

#define MALLOC(count, type) ((type *)malloc((count) * sizeof(type)))

and use it without a cast :

char *p = MALLOC(n, char);

that will work in both C and C++, and enforce consistency between allocation and
use.

Of course a compiler that does not complain about calling a function without
proper prototype is either broken or misconfigured. Fix that first.

Chqrlie.

 

[Dan Pop]

Your XMALLOC is probably clearer than the one I came up with, but I'm
going to show it off because I think it's kinda clever.

#define XMALLOC(size) malloc((size) + ((size)==0))

(Yes, I habitually parenthesize references to arguments to
function-like macros; it's easier than figuring out when it isn't
necessary.)

Of course, either macro is a potential problem if you do
p = XMALLOC( size_array[i++] );

The names are spelled in upper case to warn the user that they're macros,
not functions. If the user chooses to ignore the warnings, he gets
exactly what he deserves.

Dan

 

[Dan Pop]

Of course a compiler that does not complain about calling a function without
proper prototype is either broken or misconfigured. Fix that first.

A conforming C89 compiler need not be configurable to complain about that.

Dan

 

[Charlie Gordon]

Granted.

A compiler that does not complain about calling a function without
proper prototype is either outdated or misconfigured or outdated. Fix that
first.

Chqrlie.

 

[Keith Thompson]

Granted.

A compiler that does not complain about calling a function without
proper prototype is either outdated or misconfigured or outdated. Fix that
first.

That's not always an option, and a good C programmer should be able to
work even with outdated tools. Your compiler doesn't require you to
include the right headers? Do it anyway.

Surprise your compiler. Write better code than it asks you to.

 

[Charlie Gordon]

That's not always an option, and a good C programmer should be able to
work even with outdated tools. Your compiler doesn't require you to
include the right headers? Do it anyway.

The vast majority of posters with such problems (calling unprototyped functions)
use fine compilers with default options : none. It is a shame to give newbie C
programmers "full fledged" environments that do not enforce a minimum of
consistency checking, especially when all the needed support is readily
available from the compiler. Turn those warnings on.

Surprise your compiler. Write better code than it asks you to.

Yes, but make it ask you to if it can. Know your tools and take advandage of
them !

Chqrlie

 

[Keith Thompson]

The vast majority of posters with such problems (calling
unprototyped functions) use fine compilers with default options :
none. It is a shame to give newbie C programmers "full fledged"
environments that do not enforce a minimum of consistency checking,
especially when all the needed support is readily available from the
compiler. Turn those warnings on.


Yes, but make it ask you to if it can. Know your tools and take
advandage of them !

(Please keep your lines down to 72 columns or so. I've reformatted
some of the quoted text here.)

My followup implied more disagreement than I intended. Certainly you
should use good tools (including compilers that issue good warnings)
whenever possible. No matter how careful you are, you'll make
mistakes, and a good compiler may catch *some* of them for you.

You wrote "Fix that first", meaning to use a better compiler. I agree
with the "Fix that", but not necessarily with the "first". You need
to be careful to write good code in the first place, *and* you should
use the best compiler available with the best set of options. The
first is always possible with some effort and knowledge; the second is
usually possible, but not always.

And of course no compiler can catch all your errors. Experienced
programmers know this; newbies need to learn it.