Confused with malloc

P

pete

Richard said:
Let me guess: you tend to forget to #include <stdlib.h>?

Some programmers won't, #include stdlib.h
in a C file which uses stdlib functions,
if stdlib.h is already #included
in another header file for another C file,
which that C file, links with.

That's a mistake.

As the headers for other files,
evolve during the course of program developement,
whether or not the prototype for the function is still in scope
in the malloc using C file, changes,
and the programmer won't understand why.

That one particular line, gives me a strong clue,
that that's how the inclusion of standard library headers
is being treated in your code.
It's a mistake.
 
K

Kevin Goodsell

imemyself said:

Please don't top-post. It's rude. Also, trim the message you are
replying to. Leave only the relevant section (or alternatively, write
your own short summary).
This will be out of topic, but I have something to say regarding the
casting in malloc.

Though the usual standards say that the casting in malloc is not
neccessary, I have found programs crashing with SIGILL, SIGBUS, and
SIGSEGV in my Solaris environment. This behaviour is when I use the 64
bit FORTE compiler to compile my code.

Then either the code was broken or the compiler was broken (experience
shows that the former is much more likely, but the latter is still
possible). This doesn't have much to do with what the best practice in C is.
In my case, if the void pointer returned from Malloc is not casted to
the one assigned to, then the program crashes under high(sometimes
low) virtual memory consumption. Casting the void pointers have solved
lot of problems for me.

All other things being equal, the cast should be a no-op (no difference
at run-time, it basically only effects what diagnostics the compiler
might issue).

-Kevin
 
K

Kevin Goodsell

Richard said:
Let me guess: you tend to forget to #include <stdlib.h>?

The description of the problem didn't really sound consistent with that
error, at least to me. If the cast is needed to prevent run-time errors
rather than compile-time errors - well, that's just messed up. I want to
guess that malloc's memory pool has been corrupted, but that doesn't
quite sound right. The cast shouldn't fix that kind of error - it
shouldn't change anything at all (at run-time).

Maybe it's a compiler bug. If the description given is accurate, that
actually seems to be the most likely answer (even as unlikely as it
usually is, relatively speaking).

-Kevin
 
M

Mark McIntyre

Some programmers won't, #include stdlib.h
in a C file which uses stdlib functions,
if stdlib.h is already #included
in another header file for another C file,
which that C file, links with.

I'm sure this has been mentioned before, but your line length is so
short its actually slightly hard to read - you seem to be writing in
either blank verse, or bad haikus.... Can I suggest selecting 65-70
chars as your wrap point, instead of around 40 chars?
 
C

CBFalconer

imemyself said:
Though the usual standards say that the casting in malloc is not
neccessary, I have found programs crashing with SIGILL, SIGBUS,
and SIGSEGV in my Solaris environment. This behaviour is when I
use the 64 bit FORTE compiler to compile my code.

In my case, if the void pointer returned from Malloc is not
casted to the one assigned to, then the program crashes under
high(sometimes low) virtual memory consumption. Casting the void
pointers have solved lot of problems for me.

Strange thing is not all the void pointers I have not casted
gives me problems.

Please don't toppost. It is not condoned in c.l.c., and is rude.

I think you have a well documented complaint to the compiler
vendor. It seems to be failing some of the most elementary
requirements. This assumes you have "#include <stdlib.h>", since
you show no code.
 
R

Richard Bos

Kevin Goodsell said:
The description of the problem didn't really sound consistent with that
error, at least to me.

Oh, I dunno. A lax compiler (or lax warning setting) combined with
illegal values being returned in the wrong register, or in the wrong
shape on the stack, sound like a reasonable cause for SIGSEGV and
plausibly SIGBUS as well, to me. Granted, SIGILL I can't figure out, but
still...

Richard
 
K

Kevin Goodsell

Richard said:
Oh, I dunno. A lax compiler (or lax warning setting) combined with
illegal values being returned in the wrong register, or in the wrong
shape on the stack, sound like a reasonable cause for SIGSEGV and
plausibly SIGBUS as well, to me. Granted, SIGILL I can't figure out, but
still...

I don't really see that. Without <stdlib.h> and without a cast, a
diagnostic is required, right? OK, so the compiler could possibly get
this wrong (particularly if it is not invoked in strict
standard-compliance mode), or a warning could be issued and ignored. In
that case, run-time errors are a definite possibility. But a cast fixing
those errors? That I have a hard time understanding.

-Kevin
 
T

The Real OS/2 Guy

#define ALLOC(type) (type *)malloc(sizeof(type))

Makes bad things much bader. Whenever you frget to #include stdlib
your gets no warning but garbidge. malloc without prototyppe gets
interpreted as int mall() and this gets you code like:

1. call malloc
2. convert the value now in the place a function returned int to a
pointer of type the cast requires
3. later you'll dereference this garbidge - causing some undefined
behavior

Not every compiler uses one and the same location with exactly the
same number of bits for int and pointer to something.

So casting the return value <pointer to void> to something else means
invoking undefined behavior in any case even when the compiler does
send a diagnostic because YOU have forced the compiler to avoid any
diagnostic by telling him I KNOW THAT THE INT malloc returns IS in
reality a pointer - whereas it was YOU bug to avoid #include
<stdlib.h> - so the compiler will thing: "ok, the ill guy in front of
the screen knows that I can't know what malloc() does really, becaue
he has not telled me how to find the prototype. So I will assume that
it returns int and ignore anything that is on the place a function
returns void* has modified. It would be garbidge - but as the guy
tells me I will suppress any warning and transform that garbidge to be
a pointer of xy. Hopefully the program will crash some thousend lines
of source later."

Don't come with: but in C++.... because when you writes C++ then you
have to avoid the malloc family completely, you fave to use new/delete
instead.
 
T

The Real OS/2 Guy

No, they don't. This is a function _definition_, and in a function
definition sometype function() and sometype function(void) mean exactly
the same thing: function() is a function taking no arguments and
returning a value of type sometype.

No. int main() is a function with an incomplete list of parameters,
whereas int main(void) tells differently: no arguments accepted. An
incomplete list of parameters tells nothing about the number and types
of parameters - but allows both, any number of any types of actual
parameters.


What you say _is_ true for function declarations:

sometype function(void);

means: I have, somewhere, defined a function called function(), taking
no arguments, and returning a sometype; but

sometype function();

means: I have, somewhere, defined a function called function(),
returning a sometype, and I'm not telling you what kind of arguments it
takes.
But this is only true for declarations, not for definitions.

Richard

But int main() { is a definition! That means the calling point itself
has

int main() an unknown number of parameters with unknown types and
names. This is definitely something else than the definition of

int main(void) { a clearly written statement that says that NO
parameter is accepted.

Saying NONE is quite different from some unspezified number with some
unspezified types.
 
T

The Real OS/2 Guy

Hi,

This will be out of topic, but I have something to say regarding the
casting in malloc.

Though the usual standards say that the casting in malloc is not
neccessary, I have found programs crashing with SIGILL, SIGBUS, and
SIGSEGV in my Solaris environment. This behaviour is when I use the 64
bit FORTE compiler to compile my code.

In my case, if the void pointer returned from Malloc is not casted to
the one assigned to, then the program crashes under high(sometimes
low) virtual memory consumption. Casting the void pointers have solved
lot of problems for me.

Strange thing is not all the void pointers I have not casted gives me
problems.
Its random.

You've forgot to announce the prototype of malloc() to the translation
unit! The compiler is NOT obligated to warn you on that fact anyway.
It is even not oblicated to give you an diganostic by

int a[10);
float f = a;

Even as this is rarely that what you would mean.

Whenever a compiler lets your code crash by

#include <stdlib>

int main(void) {
int *p = malloc(1000 * sizeof(*p));
.....

then your compiler is definitely NOT a C compiler - independant of
each conceivable platform.

Never use a C++ compiler to compile a C program - it won't work.
 
K

Kevin Goodsell

The said:
Makes bad things much bader. Whenever you frget to #include stdlib
your gets no warning but garbidge. malloc without prototyppe gets
interpreted as int mall() and this gets you code like:

I'm well aware of that, thanks. (You probably could have figured that
out from the dozens of times I've explained that exact situation to
other people on this group.) All I was saying is that if you *really*
want/need to cast malloc's return for some reason (for example, if you
are writing in the common subset of C and C++), this method helps to
make sure that you cast to the same type that you allocate space for.

-Kevin
 
S

Sidney Cadot

The said:
#define ALLOC(type) (type *)malloc(sizeof(type))


Makes bad things much bader. Whenever you frget to #include stdlib
your gets no warning but garbidge. malloc without prototyppe gets
interpreted as int mall() and this gets you code like:

1. call malloc
2. convert the value now in the place a function returned int to a
pointer of type the cast requires
3. later you'll dereference this garbidge - causing some undefined
behavior

Not every compiler uses one and the same location with exactly the
same number of bits for int and pointer to something.

So casting the return value <pointer to void> to something else means
invoking undefined behavior in any case even when [...]

I hope you're not saying here that casting a void* to another pointer
type is UB (just checking).
the compiler does
send a diagnostic because YOU have forced the compiler to avoid any
diagnostic by telling him I KNOW THAT THE INT malloc returns IS in
reality a pointer - whereas it was YOU bug to avoid #include
<stdlib.h> - so the compiler will thing: "ok, the ill guy in front of
the screen knows that I can't know what malloc() does really, becaue
he has not telled me how to find the prototype. So I will assume that
it returns int and ignore anything that is on the place a function
returns void* has modified. It would be garbidge - but as the guy
tells me I will suppress any warning and transform that garbidge to be
a pointer of xy. Hopefully the program will crash some thousend lines
of source later."

Don't come with: but in C++.... because when you writes C++ then you
have to avoid the malloc family completely,

"have to?" Says who? It's perfectly well-defined.
you fave to use new/delete instead.

Best regards,

Sidney
 
T

The Real OS/2 Guy

I hope you're not saying here that casting a void* to another pointer
type is UB (just checking).

No, I'm saying that cating the return value of a function that returns
pointer to void is going to be UB when the prototype of the fuction is
not visible to the compiler.

I say further that casting a pointer to void to something else is
completely useless.
 
T

The Real OS/2 Guy

I'm well aware of that, thanks. (You probably could have figured that
out from the dozens of times I've explained that exact situation to
other people on this group.) All I was saying is that if you *really*
want/need to cast malloc's return for some reason (for example, if you
are writing in the common subset of C and C++), this method helps to
make sure that you cast to the same type that you allocate space for.

-Kevin

There is absolutely no reason to compile C with a C++ compiler. Or
likes you to compile C with a Cobol, Fortran or Pascal compiler too?

Either you use malloc - then you have to use a C compiler or you use
new - that is the equivalent of C++.

Or you have a programming logic that is generelly errornpus because
you are unable to make a well defined program design.

Make a well design of your program - and you will never use a C++
compiler to compile C because there are other methods to get C
functions called from C++ without recompiling them with a compiler
that is not designed to do so.
 
K

Kevin Goodsell

The said:
There is absolutely no reason to compile C with a C++ compiler. Or
likes you to compile C with a Cobol, Fortran or Pascal compiler too?

Maybe you should go back and read P.J. Plauger's posts on the subject.
Clearly some people *do* find reasons to compile C with a C++ compiler.
Personally I've never had a good reason to do so, but that doesn't mean
that reasons don't exist.

-Kevin
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

malloc 33
Queue in C 25
struct/malloc failure 3
explicit cast to malloc() 5
malloc and functions 24
Linux: using "clone3" and "waitid" 0
problem with feof ? 21
using my own malloc() 14

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top