Looking for malloc() help

[SP]

I am learning C and have a question re: malloc().

I wrote simple program which assigns a value to a structure and then
prints it as follow:

#include <stdio.h>
#include <stdlib.h>

struct item {
char name[20];
int quantity;
};

int main (int argc, char *argv[])
{
struct item *stuff;

//allocate memory for structure
stuff = malloc(3 * sizeof(struct item));

strcpy(stuff[1].name, "apple");
stuff[1].quantity = 1;
strcpy(stuff[2].name, "banana");
stuff[2].quantity = 2;

printf("%s %d\n", stuff[1].name, st.quantity);
printf("%s %d\n", stuff[2].name, st.quantity);

free(stuff);
return 0;
}

I then change the structure declaration in order to dynamically
allocate memory
for the char array:
struct item {
char *name;
int quantity;
};

The program compiles with no errors, but it crashes with the following
error:

line 3: 2485 Segmentation fault

Thanks for your help

[Harald van Dijk]

Herbert Rosenau wrote:

On Thu, 3 Aug 2006 03:02:20 UTC, "xiaohuamao "
<ca************ **@gmail.comwro te:

I don't know what is the problem. The following code works in my
machine.
struct item {
char* name;
int quantity;
};

int main ()
{
struct item *stuff;

//allocate memory for structure
stuff = (struct item *)malloc(3 * sizeof(struct item));

Never ever cast the result from malloc() except you like to go into
the lands of undefined behavior and you dont like to get diagnostics
from your compiler when you've forget to include stdlib.h.

Or if you want C++ compatibility, for whatever reason. (It may not make
sense for most C code, but one of the times it does make sense is if
it's an inline function in a header file that's kept after
installation.)

Never ever cast something - excet you knows exactly what you're
doing. casting the result of a function returning void* is playing
with the health of y<or app because you does NOT know what you does.
When you would know what you does you would never cast that.

You can quite legitimately cast a void * return value if you want to
store it as an (u)intptr_t value.

I wouldn't have commented if you hadn't so specifically said "never".

[Joe Wright]

SP wrote:

I am learning C and have a question re: malloc().

I wrote simple program which assigns a value to a structure and then
prints it as follow:

#include <stdio.h>
#include <stdlib.h>

struct item {
char name[20];
int quantity;
};

int main (int argc, char *argv[])
{
struct item *stuff;

//allocate memory for structure
stuff = malloc(3 * sizeof(struct item));

strcpy(stuff[1].name, "apple");
stuff[1].quantity = 1;
strcpy(stuff[2].name, "banana");
stuff[2].quantity = 2;

printf("%s %d\n", stuff[1].name, st.quantity);
printf("%s %d\n", stuff[2].name, st.quantity);

free(stuff);
return 0;
}

I then change the structure declaration in order to dynamically
allocate memory
for the char array:
struct item {
char *name;
int quantity;
};

The program compiles with no errors, but it crashes with the following
error:

line 3: 2485 Segmentation fault

Thanks for your help

But you didn't allocate the memory. You'll need something like..

stuff[1].name = malloc(20);

...before

strcpy(stuff[1].name, "apple");

...and then you must free stuff[1].name (and stuff[2].name) before
freeing stuff.
--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Herbert Rosenau]

On Fri, 4 Aug 2006 06:27:22 UTC, "Harald van Dk" <tr*****@gmail. com>
wrote:

Herbert Rosenau wrote:

Never ever cast the result from malloc() except you like to go into
the lands of undefined behavior and you dont like to get diagnostics
from your compiler when you've forget to include stdlib.h.

Or if you want C++ compatibility, for whatever reason. (It may not make
sense for most C code, but one of the times it does make sense is if
it's an inline function in a header file that's kept after
installation.)

No. In C++ you would use simply operator new.

Never ever cast something - excet you knows exactly what you're
doing. casting the result of a function returning void* is playing
with the health of y<or app because you does NOT know what you does.
When you would know what you does you would never cast that.

You can quite legitimately cast a void * return value if you want to
store it as an (u)intptr_t value.

You can burn your home, no question. Bit is it a good idea to do so?
You can kill your wife too. Casting is insidious and casing void* to
anything else says nothing but you knows not how to handle pointers to
void.

I wouldn't have commented if you hadn't so specifically said "never".

It is simply: never ever cast the result of a function returning a
pointer to void. You'll end up in the lands of undifined behavior..

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

[Harald van Dijk]

Herbert Rosenau wrote:

On Fri, 4 Aug 2006 06:27:22 UTC, "Harald van Dk" <tr*****@gmail. com>
wrote:

Herbert Rosenau wrote:

>
Never ever cast the result from malloc() except you like to go into
the lands of undefined behavior and you dont like to get diagnostics
from your compiler when you've forget to include stdlib.h.

Or if you want C++ compatibility, for whatever reason. (It may not make
sense for most C code, but one of the times it does make sense is if
it's an inline function in a header file that's kept after
installation.)

No. In C++ you would use simply operator new.

new is not an option when writing header files that work both for C and
for C++ code.

Never ever cast something - excet you knows exactly what you're
doing. casting the result of a function returning void* is playing
with the health of y<or app because you does NOT know what you does.
When you would know what you does you would never cast that.

You can quite legitimately cast a void * return value if you want to
store it as an (u)intptr_t value.

You can burn your home, no question. Bit is it a good idea to do so?
You can kill your wife too. Casting is insidious and casing void* to
anything else says nothing but you knows not how to handle pointers to
void.

How would you use (u)intptr_t, then? (If you say you wouldn't at all,
keep in mind that it's a type defined in standard C(99).)

I wouldn't have commented if you hadn't so specifically said "never".

It is simply: never ever cast the result of a function returning a
pointer to void. You'll end up in the lands of undifined behavior..

That's clearly untrue, and depending on your intent quite possibly a
lie. There's no undefined behaviour in casting the result of malloc().
It's usually poor style, and it can cover up warnings when the
behaviour would be just as undefined without a cast, but that's all.

[Herbert Rosenau]

On Sun, 6 Aug 2006 14:47:01 UTC, "Harald van Dk" <tr*****@gmail. com>
wrote:

Herbert Rosenau wrote:

On Fri, 4 Aug 2006 06:27:22 UTC, "Harald van Dk" <tr*****@gmail. com>
wrote:

Herbert Rosenau wrote:

Never ever cast the result from malloc() except you like to go into
the lands of undefined behavior and you dont like to get diagnostics
from your compiler when you've forget to include stdlib.h.
>
Or if you want C++ compatibility, for whatever reason. (It may not make
sense for most C code, but one of the times it does make sense is if
it's an inline function in a header file that's kept after
installation.)

No. In C++ you would use simply operator new.

new is not an option when writing header files that work both for C and
for C++ code.

But you says that it is good to write programs for both C anf FORTRAN
or C++ and Cobol?
You can't write a single program that uses two highly different
languages. When you needs to write failsave programs instead of
hacking blind around you have to use either C or C++. Mixing up
languages inside the same program ends always up with holes of any
kind.

Never ever cast something - excet you knows exactly what you're
doing. casting the result of a function returning void* is playing
with the health of y<or app because you does NOT know what you does.
When you would know what you does you would never cast that.
>
You can quite legitimately cast a void * return value if you want to
store it as an (u)intptr_t value.

You can burn your home, no question. Bit is it a good idea to do so?
You can kill your wife too. Casting is insidious and casing void* to
anything else says nothing but you knows not how to handle pointers to
void.

How would you use (u)intptr_t, then? (If you say you wouldn't at all,
keep in mind that it's a type defined in standard C(99).)

I would use it as it is defined. Conversion between all kinds of data
pointer to/from pointer to void is done already witrhout cast. When
you does not know what you does you should avoid cats anyway.

I wouldn't have commented if you hadn't so specifically said "never".

It is simply: never ever cast the result of a function returning a
pointer to void. You'll end up in the lands of undifined behavior..

That's clearly untrue, and depending on your intent quite possibly a
lie. There's no undefined behaviour in casting the result of malloc().
It's usually poor style, and it can cover up warnings when the
behaviour would be just as undefined without a cast, but that's all.

You must learn C before you can use the language, so start learning C.
Until you have learned C you are absolutely unable to something about
the language. You've proven now that you knows nothing about C.

Will you guarantee that in each and any environment a function
returning a pointer uses always the same location as a function
returning int, even as the standard since more than 15 years says the
contrary.

You knows nothing about C but tells nonsense. There are more traps you
falls in as you can dream of when you does not understund what C is -
and you have not even basic knowlede about C yet.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

[Keith Thompson]

"Herbert Rosenau" <os****@pc-rosenau.dewrite s:

On Sun, 6 Aug 2006 14:47:01 UTC, "Harald van Dk" <tr*****@gmail. com>
wrote:

>Herbert Rosenau wrote:

On Fri, 4 Aug 2006 06:27:22 UTC, "Harald van Dk" <tr*****@gmail. com>
wrote:

Herbert Rosenau wrote:


Never ever cast the result from malloc() except you like to go into
the lands of undefined behavior and you dont like to get diagnostics
from your compiler when you've forget to include stdlib.h.

Or if you want C++ compatibility, for whatever reason. (It may not make
sense for most C code, but one of the times it does make sense is if
it's an inline function in a header file that's kept after
installation.)

No. In C++ you would use simply operator new.

new is not an option when writing header files that work both for C and
for C++ code.

But you says that it is good to write programs for both C anf FORTRAN
or C++ and Cobol?

No, he didn't say that.

You can't write a single program that uses two highly different
languages. When you needs to write failsave programs instead of
hacking blind around you have to use either C or C++. Mixing up
languages inside the same program ends always up with holes of any
kind.

C and C++ are not "highly different"; C is nearly (but not exactly) a
subset of C++, and it's possible to write reasonable code within the
intersection of the two languages.

It rarely makes sense to do so. 99% of the time, it makes more sense
to write in pure C, or to write in pure C++, or to use C++'s 'extern
"C"' mechanism if you need to use both. But it's also possible to
write library code that's intended to be used by either C or C++
client code. P.J. Plauger does this, for example.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Heathfield]

Keith Thompson said:

<snip>

But it's also possible to
write library code that's intended to be used by either C or C++
client code. P.J. Plauger does this, for example.

And the reason his name is always given as an example is that he's almost
the only guy in the universe with a good reason to do this.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Harald van Dijk]

Herbert Rosenau wrote:

On Sun, 6 Aug 2006 14:47:01 UTC, "Harald van Dk" <tr*****@gmail. com>
wrote:

Never ever cast something - excet you knows exactly what you're
doing. casting the result of a function returning void* is playing
with the health of y<or app because you does NOT know what you does.
When you would know what you does you would never cast that.

You can quite legitimately cast a void * return value if you want to
store it as an (u)intptr_t value.
>
You can burn your home, no question. Bit is it a good idea to do so?
You can kill your wife too. Casting is insidious and casing void* to
anything else says nothing but you knows not how to handle pointers to
void.

How would you use (u)intptr_t, then? (If you say you wouldn't at all,
keep in mind that it's a type defined in standard C(99).)

I would use it as it is defined. Conversion between all kinds of data
pointer to/from pointer to void is done already witrhout cast. When
you does not know what you does you should avoid cats anyway.

It is impossible in standard C to store a pointer value in an
(u)intptr_t object without a cast. Using a cast in this case, according
to you, shows you don't know how to handle pointers. So I ask again,
how would you use (u)intptr_t?

I wouldn't have commented if you hadn't so specifically said "never".
>
It is simply: never ever cast the result of a function returning a
pointer to void. You'll end up in the lands of undifined behavior..

That's clearly untrue, and depending on your intent quite possibly a
lie. There's no undefined behaviour in casting the result of malloc().
It's usually poor style, and it can cover up warnings when the
behaviour would be just as undefined without a cast, but that's all.

[Insult snipped]
Will you guarantee that in each and any environment a function
returning a pointer uses always the same location as a function
returning int, even as the standard since more than 15 years says the
contrary.
[Insult snipped]

No, that's clearly untrue, no disagreement there, but where is the
undefined behaviour in this program?

#include <stdlib.h>
int main(void) {
free( (char *) malloc(1) );
}

What I said, if you would re-read my message, is that the cast itself
does not invoke undefined behaviour. What does invoke undefined
behaviour is giving an improper declaration of malloc(), but malloc()
is properly declared here. A cast can happen to hide a diagnostic
caused by an improper declaration, but the behaviour is not defined
with or without it.

[Ian Collins]

Herbert Rosenau wrote:

On Sun, 6 Aug 2006 14:47:01 UTC, "Harald van D�k" <tr*****@gmail. com>
wrote:

>>Herbert Rosenau wrote:

>>>On Fri, 4 Aug 2006 06:27:22 UTC, "Harald van D�k" <tr*****@gmail. com>
wrote:
Herbert Rosenau wrote:

>Never ever cast the result from malloc() except you like to go into
>the lands of undefined behavior and you dont like to get diagnostics
>from your compiler when you've forget to include stdlib.h.

Or if you want C++ compatibility, for whatever reason. (It may not make
sense for most C code, but one of the times it does make sense is if
it's an inline function in a header file that's kept after
installatio n.)

No. In C++ you would use simply operator new.

new is not an option when writing header files that work both for C and
for C++ code.

But you says that it is good to write programs for both C anf FORTRAN
or C++ and Cobol?

Where did "programs' come from? The discussion was about headers.

>
You can't write a single program that uses two highly different
languages. When you needs to write failsave programs instead of
hacking blind around you have to use either C or C++. Mixing up
languages inside the same program ends always up with holes of any
kind.

But they do (often) share headers.

--
Ian Collins.

[J. J. Farrell]

Herbert Rosenau wrote:

On Sun, 6 Aug 2006 14:47:01 UTC, "Harald van Dk" <tr*****@gmail. com>
wrote:

Herbert Rosenau wrote:

On Fri, 4 Aug 2006 06:27:22 UTC, "Harald van Dk" <tr*****@gmail. com>
wrote:
Herbert Rosenau wrote:
Never ever cast something - excet you knows exactly what you're
doing. casting the result of a function returning void* is playing
with the health of y<or app because you does NOT know what you does.
When you would know what you does you would never cast that.

You can quite legitimately cast a void * return value if you want to
store it as an (u)intptr_t value.
>
You can burn your home, no question. Bit is it a good idea to do so?
You can kill your wife too. Casting is insidious and casing void* to
anything else says nothing but you knows not how to handle pointers to
void.

How would you use (u)intptr_t, then? (If you say you wouldn't at all,
keep in mind that it's a type defined in standard C(99).)

I would use it as it is defined. Conversion between all kinds of data
pointer to/from pointer to void is done already witrhout cast. When
you does not know what you does you should avoid cats anyway.

Please show us your code to store a void * in a uintptr_t without a
cast.

...

You must learn C before you can use the language, so start learning C.
Until you have learned C you are absolutely unable to something about
the language. You've proven now that you knows nothing about C.

Hmmm ...

Will you guarantee that in each and any environment a function
returning a pointer uses always the same location as a function
returning int, even as the standard since more than 15 years says the
contrary.

How's that relevant?

You knows nothing about C but tells nonsense. There are more traps you
falls in as you can dream of when you does not understund what C is -
and you have not even basic knowlede about C yet.

You need to be on more solid ground than you are to make comments like
these without looking foolish.