472,122 Members | 1,554 Online

Problem with malloc

Hi,
I have the following problem, I must to do my assignment, but I really do
not know how to use the malloc.
I need create a program that will be used to do some algebrical computation
on the matrix.
How I can create dynamical the matrices with the name in order to be able to
recall them.
Thx
Nov 14 '05 #1
66 3013
Hi,
I have the following problem, I must to do my assignment, but I really do
not know how to use the malloc.
I need create a program that will be used to do some algebrical
computation on the matrix.
How I can create dynamical the matrices with the name in order to be able
to recall them.

step 1. "man malloc"
step 2. Pay attention in class when they teach you how to use pointers.
step 3. Don't ask for homework solutions in usenet.

Tom
Nov 14 '05 #2
Hi,
I have the following problem, I must to do my assignment, but I really do
not know how to use the malloc.
I need create a program that will be used to do some algebrical
computation on the matrix.
How I can create dynamical the matrices with the name in order to be able
to recall them.

step 1. "man malloc"
step 2. Pay attention in class when they teach you how to use pointers.
step 3. Don't ask for homework solutions in usenet.

Tom
Nov 14 '05 #3
Tom St Denis <to*@securescience.net> scribbled the following:
Hi,
I have the following problem, I must to do my assignment, but I really do
not know how to use the malloc.
I need create a program that will be used to do some algebrical
computation on the matrix.
How I can create dynamical the matrices with the name in order to be able
to recall them.

step 1. "man malloc"

What makes you so sure Knady is working on a UNIX system?

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"O pointy birds, O pointy-pointy. Anoint my head, anointy-nointy."
- Dr. Michael Hfuhruhurr
Nov 14 '05 #4
Tom St Denis <to*@securescience.net> scribbled the following:
Hi,
I have the following problem, I must to do my assignment, but I really do
not know how to use the malloc.
I need create a program that will be used to do some algebrical
computation on the matrix.
How I can create dynamical the matrices with the name in order to be able
to recall them.

step 1. "man malloc"

What makes you so sure Knady is working on a UNIX system?

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"O pointy birds, O pointy-pointy. Anoint my head, anointy-nointy."
- Dr. Michael Hfuhruhurr
Nov 14 '05 #5
On Sun, 04 Apr 2004 12:08:27 +0000, Tom St Denis wrote:
Hi,
I have the following problem, I must to do my assignment, but I really do
not know how to use the malloc.
I need create a program that will be used to do some algebrical
computation on the matrix.
How I can create dynamical the matrices with the name in order to be able
to recall them.

Do you know how to do it without dynamic memory (for a fixed sice
matrix?), start out with that and modify it to use dynamic memory.

step 1. "man malloc"
step 2. Pay attention in class when they teach you how to use pointers.
step 3. Don't ask for homework solutions in usenet.

Atleat he was honest about it beeing homework.

Step 4. Try to code something up yourself
Step 5. If you can't get it to work post the code that you have and
someone will probably point out your errors.

--
NPV

What did that old blonde gal say? -- That is the part you throw away.
Tom Waits - The part you throw away

Nov 14 '05 #6
On Sun, 04 Apr 2004 12:08:27 +0000, Tom St Denis wrote:
Hi,
I have the following problem, I must to do my assignment, but I really do
not know how to use the malloc.
I need create a program that will be used to do some algebrical
computation on the matrix.
How I can create dynamical the matrices with the name in order to be able
to recall them.

Do you know how to do it without dynamic memory (for a fixed sice
matrix?), start out with that and modify it to use dynamic memory.

step 1. "man malloc"
step 2. Pay attention in class when they teach you how to use pointers.
step 3. Don't ask for homework solutions in usenet.

Atleat he was honest about it beeing homework.

Step 4. Try to code something up yourself
Step 5. If you can't get it to work post the code that you have and
someone will probably point out your errors.

--
NPV

What did that old blonde gal say? -- That is the part you throw away.
Tom Waits - The part you throw away

Nov 14 '05 #7
Joona I Palaste wrote:
Tom St Denis <to*@securescience.net> scribbled the following:

Hi,
I have the following problem, I must to do my assignment, but I really
do not know how to use the malloc.
I need create a program that will be used to do some algebrical
computation on the matrix.
How I can create dynamical the matrices with the name in order to be
able to recall them.

step 1. "man malloc"

What makes you so sure Knady is working on a UNIX system?

Who cares if he isn't? Stupid windows users can trap themselves in
ignorance for all I care. As for me and my Gentoo'd box I'll go hug my
manual pages now... ;-)

Tom
Nov 14 '05 #8
Joona I Palaste wrote:
Tom St Denis <to*@securescience.net> scribbled the following:

Hi,
I have the following problem, I must to do my assignment, but I really
do not know how to use the malloc.
I need create a program that will be used to do some algebrical
computation on the matrix.
How I can create dynamical the matrices with the name in order to be
able to recall them.

step 1. "man malloc"

What makes you so sure Knady is working on a UNIX system?

Who cares if he isn't? Stupid windows users can trap themselves in
ignorance for all I care. As for me and my Gentoo'd box I'll go hug my
manual pages now... ;-)

Tom
Nov 14 '05 #9

How I can create dynamical the matrices with the name in order to > be able to recall them.

To create a matrix

double *mtx = malloc(width * height * sizeof(double));
if(mtx == 0)
/* out of memory */

To access an element

double element = mtx[y * width + x];

Once you've finished

free(mtx);
Nov 14 '05 #10

How I can create dynamical the matrices with the name in order to > be able to recall them.

To create a matrix

double *mtx = malloc(width * height * sizeof(double));
if(mtx == 0)
/* out of memory */

To access an element

double element = mtx[y * width + x];

Once you've finished

free(mtx);
Nov 14 '05 #11

Hi,
I have the following problem, I must to do my assignment, but I really do
not know how to use the malloc.
I need create a program that will be used to do some algebrical computation
on the matrix.
How I can create dynamical the matrices with the name in order to be able to
recall them.
Thx

The faq is a good source for help on multidimensional array dynamic

http://www.eskimo.com/~scs/C-faq/q6.16.html

--
Al Bowers
Tampa, Fl USA
mailto: xa******@myrapidsys.com (remove the x to send email)
http://www.geocities.com/abowers822/

Nov 14 '05 #12

Hi,
I have the following problem, I must to do my assignment, but I really do
not know how to use the malloc.
I need create a program that will be used to do some algebrical computation
on the matrix.
How I can create dynamical the matrices with the name in order to be able to
recall them.
Thx

The faq is a good source for help on multidimensional array dynamic

http://www.eskimo.com/~scs/C-faq/q6.16.html

--
Al Bowers
Tampa, Fl USA
mailto: xa******@myrapidsys.com (remove the x to send email)
http://www.geocities.com/abowers822/

Nov 14 '05 #13
Anyone know why engineers get such a bad reputation for being antisocial?
Instead of wasting my time berating you for being a "stupid windows user"

It's actually quite simple... Malloc returns a pointer to a chunk of memory
of a certain size in bytes. You specify the number of bytes in the
parameter you pass to malloc. The prototype for malloc is
void *malloc(int size);

So, you get a void pointer in return... you need to cast it to something
useable, like your matrix, for instance...

typedef int my_matrix_t[20][20];//Hope I did this typedef right!

//Allocate memory for matrix and store in pointer. Cast so compiler doesn't
puke.
my_matrix_t *pmatrix = (my_matrix_t *)malloc(sizeof(my_matrix_t));
news:3L******************@news.nnrp.ca...
Hi,
I have the following problem, I must to do my assignment, but I really do
not know how to use the malloc.
I need create a program that will be used to do some algebrical computation on the matrix.
How I can create dynamical the matrices with the name in order to be able to recall them.
Thx

Nov 14 '05 #14
Anyone know why engineers get such a bad reputation for being antisocial?
Instead of wasting my time berating you for being a "stupid windows user"

It's actually quite simple... Malloc returns a pointer to a chunk of memory
of a certain size in bytes. You specify the number of bytes in the
parameter you pass to malloc. The prototype for malloc is
void *malloc(int size);

So, you get a void pointer in return... you need to cast it to something
useable, like your matrix, for instance...

typedef int my_matrix_t[20][20];//Hope I did this typedef right!

//Allocate memory for matrix and store in pointer. Cast so compiler doesn't
puke.
my_matrix_t *pmatrix = (my_matrix_t *)malloc(sizeof(my_matrix_t));
news:3L******************@news.nnrp.ca...
Hi,
I have the following problem, I must to do my assignment, but I really do
not know how to use the malloc.
I need create a program that will be used to do some algebrical computation on the matrix.
How I can create dynamical the matrices with the name in order to be able to recall them.
Thx

Nov 14 '05 #15
Chris Fogelklou wrote:
Anyone know why engineers get such a bad reputation for being antisocial?
Instead of wasting my time berating you for being a "stupid windows user"
And even at that you failed.
It's actually quite simple... Malloc returns a pointer to a chunk of
memory
of a certain size in bytes. You specify the number of bytes in the
parameter you pass to malloc. The prototype for malloc is
void *malloc(int size);
That's not the prototype for malloc. It's

void *malloc(size_t size);
So, you get a void pointer in return... you need to cast it to something
useable, like your matrix, for instance...
Um, no. In C you need not cast void pointers.
typedef int my_matrix_t[20][20];//Hope I did this typedef right!
This isn't dynamic though [hint: read the OPs question] it's always 20x20
//Allocate memory for matrix and store in pointer. Cast so compiler
doesn't puke.
my_matrix_t *pmatrix = (my_matrix_t *)malloc(sizeof(my_matrix_t));

If your compiler pukes at that (without the cast) then you need a new
compiler.

Tom
Nov 14 '05 #16
Chris Fogelklou wrote:
Anyone know why engineers get such a bad reputation for being antisocial?
Instead of wasting my time berating you for being a "stupid windows user"
And even at that you failed.
It's actually quite simple... Malloc returns a pointer to a chunk of
memory
of a certain size in bytes. You specify the number of bytes in the
parameter you pass to malloc. The prototype for malloc is
void *malloc(int size);
That's not the prototype for malloc. It's

void *malloc(size_t size);
So, you get a void pointer in return... you need to cast it to something
useable, like your matrix, for instance...
Um, no. In C you need not cast void pointers.
typedef int my_matrix_t[20][20];//Hope I did this typedef right!
This isn't dynamic though [hint: read the OPs question] it's always 20x20
//Allocate memory for matrix and store in pointer. Cast so compiler
doesn't puke.
my_matrix_t *pmatrix = (my_matrix_t *)malloc(sizeof(my_matrix_t));

If your compiler pukes at that (without the cast) then you need a new
compiler.

Tom
Nov 14 '05 #17
Tom St Denis <to*@securescience.net> scribbled the following:
Joona I Palaste wrote:
Tom St Denis <to*@securescience.net> scribbled the following:
Hi,
I have the following problem, I must to do my assignment, but I really
do not know how to use the malloc.
I need create a program that will be used to do some algebrical
computation on the matrix.
How I can create dynamical the matrices with the name in order to be
able to recall them.
step 1. "man malloc"

What makes you so sure Knady is working on a UNIX system?

Who cares if he isn't? Stupid windows users can trap themselves in
ignorance for all I care. As for me and my Gentoo'd box I'll go hug my
manual pages now... ;-)

And what about stupid UNIX users? Oh, right. I forgot. To be able to so
much as boot up a UNIX machine you have to be both a hardware and a
software high wizard. How silly of me. =)
users. I don't like Microsoft any more than you do, but that's no
excuse to prejudice against their entire userbase.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"I will never display my bum in public again."
- Homer Simpson
Nov 14 '05 #18
Tom St Denis <to*@securescience.net> scribbled the following:
Joona I Palaste wrote:
Tom St Denis <to*@securescience.net> scribbled the following:
Hi,
I have the following problem, I must to do my assignment, but I really
do not know how to use the malloc.
I need create a program that will be used to do some algebrical
computation on the matrix.
How I can create dynamical the matrices with the name in order to be
able to recall them.
step 1. "man malloc"

What makes you so sure Knady is working on a UNIX system?

Who cares if he isn't? Stupid windows users can trap themselves in
ignorance for all I care. As for me and my Gentoo'd box I'll go hug my
manual pages now... ;-)

And what about stupid UNIX users? Oh, right. I forgot. To be able to so
much as boot up a UNIX machine you have to be both a hardware and a
software high wizard. How silly of me. =)
users. I don't like Microsoft any more than you do, but that's no
excuse to prejudice against their entire userbase.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"I will never display my bum in public again."
- Homer Simpson
Nov 14 '05 #19
Joona I Palaste wrote:
Tom St Denis <to*@securescience.net> scribbled the following:
Joona I Palaste wrote:
Tom St Denis <to*@securescience.net> scribbled the following:
> Hi,
> I have the following problem, I must to do my assignment, but I really
> do not know how to use the malloc.
> I need create a program that will be used to do some algebrical
> computation on the matrix.
> How I can create dynamical the matrices with the name in order to be
> able to recall them.

step 1. "man malloc"

What makes you so sure Knady is working on a UNIX system?

Who cares if he isn't? Stupid windows users can trap themselves in
ignorance for all I care. As for me and my Gentoo'd box I'll go hug my
manual pages now... ;-)

And what about stupid UNIX users? Oh, right. I forgot. To be able to so
much as boot up a UNIX machine you have to be both a hardware and a
software high wizard. How silly of me. =)
users. I don't like Microsoft any more than you do, but that's no
excuse to prejudice against their entire userbase.

Perhaps but honestly there aren't many "good" reasons to use Windows. For
the most part Windows lowers that standards for users.

But even if the dude is a Windows user he could search MSDN for malloc ;-)
or search for manpages online, etc, etc...The fact that the guy doesn't
know what malloc does shows he has zero research skills.

I mean it's one thing to ask standards questions [e.g. "is this in ISO C",
etc] but honestly I'd expect any half competent developer to at least
memorize the vast majority of C functions and be able to research the rest.

Tom
Nov 14 '05 #20
Joona I Palaste wrote:
Tom St Denis <to*@securescience.net> scribbled the following:
Joona I Palaste wrote:
Tom St Denis <to*@securescience.net> scribbled the following:
> Hi,
> I have the following problem, I must to do my assignment, but I really
> do not know how to use the malloc.
> I need create a program that will be used to do some algebrical
> computation on the matrix.
> How I can create dynamical the matrices with the name in order to be
> able to recall them.

step 1. "man malloc"

What makes you so sure Knady is working on a UNIX system?

Who cares if he isn't? Stupid windows users can trap themselves in
ignorance for all I care. As for me and my Gentoo'd box I'll go hug my
manual pages now... ;-)

And what about stupid UNIX users? Oh, right. I forgot. To be able to so
much as boot up a UNIX machine you have to be both a hardware and a
software high wizard. How silly of me. =)
users. I don't like Microsoft any more than you do, but that's no
excuse to prejudice against their entire userbase.

Perhaps but honestly there aren't many "good" reasons to use Windows. For
the most part Windows lowers that standards for users.

But even if the dude is a Windows user he could search MSDN for malloc ;-)
or search for manpages online, etc, etc...The fact that the guy doesn't
know what malloc does shows he has zero research skills.

I mean it's one thing to ask standards questions [e.g. "is this in ISO C",
etc] but honestly I'd expect any half competent developer to at least
memorize the vast majority of C functions and be able to research the rest.

Tom
Nov 14 '05 #21
> > Anyone know why engineers get such a bad reputation for being
antisocial?
Instead of wasting my time berating you for being a "stupid windows user" I'll answer the question...
And even at that you failed.

Hmmm... thanks.
That's not the prototype for malloc. It's

void *malloc(size_t size);

It's irrelevant to the answer, and normally size_t is an int anyway. I
could have said it's a size_t, but it might have created more problems than
So, you get a void pointer in return... you need to cast it to something
useable, like your matrix, for instance...

Um, no. In C you need not cast void pointers.

Um, yes you do, if you want truly portable code.
//Allocate memory for matrix and store in pointer. Cast so compiler
doesn't puke.
my_matrix_t *pmatrix = (my_matrix_t *)malloc(sizeof(my_matrix_t));

If your compiler pukes at that (without the cast) then you need a new
compiler.

Alright... Do you want to write one up for our embedded system? There have
two compilers, one based on GCC, and neither of them like it if you equate
two pointer types to each other without casting.
This isn't dynamic though [hint: read the OPs question] it's always 20x20

This is true, but I got the impression that he had no idea how to use
malloc. I was trying to solve his confusion relating to malloc itself.
Hopefully with this basic understanding, he can solve the dynamic part of
the problem himself. (I should have also mentioned how to use free, but
someone else did a pretty good job of that.)

The link provided by Al Bowers is an excellent source for info on the
dynamic memory problem.

Cheers,

Chris

Nov 14 '05 #22
> > Anyone know why engineers get such a bad reputation for being
antisocial?
Instead of wasting my time berating you for being a "stupid windows user" I'll answer the question...
And even at that you failed.

Hmmm... thanks.
That's not the prototype for malloc. It's

void *malloc(size_t size);

It's irrelevant to the answer, and normally size_t is an int anyway. I
could have said it's a size_t, but it might have created more problems than
So, you get a void pointer in return... you need to cast it to something
useable, like your matrix, for instance...

Um, no. In C you need not cast void pointers.

Um, yes you do, if you want truly portable code.
//Allocate memory for matrix and store in pointer. Cast so compiler
doesn't puke.
my_matrix_t *pmatrix = (my_matrix_t *)malloc(sizeof(my_matrix_t));

If your compiler pukes at that (without the cast) then you need a new
compiler.

Alright... Do you want to write one up for our embedded system? There have
two compilers, one based on GCC, and neither of them like it if you equate
two pointer types to each other without casting.
This isn't dynamic though [hint: read the OPs question] it's always 20x20

This is true, but I got the impression that he had no idea how to use
malloc. I was trying to solve his confusion relating to malloc itself.
Hopefully with this basic understanding, he can solve the dynamic part of
the problem himself. (I should have also mentioned how to use free, but
someone else did a pretty good job of that.)

The link provided by Al Bowers is an excellent source for info on the
dynamic memory problem.

Cheers,

Chris

Nov 14 '05 #23
"Chris Fogelklou" <ch*************@comhem.se> writes:
That's not the prototype for malloc. It's

void *malloc(size_t size);

It's irrelevant to the answer, and normally size_t is an int anyway.

No. According to 7.17#2, `size_t' is required to be an unsigned integer
type, so it cannot be `int'.
Um, no. In C you need not cast void pointers.

Um, yes you do, if you want truly portable code.

Martin
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/
Nov 14 '05 #24
"Chris Fogelklou" <ch*************@comhem.se> writes:
That's not the prototype for malloc. It's

void *malloc(size_t size);

It's irrelevant to the answer, and normally size_t is an int anyway.

No. According to 7.17#2, `size_t' is required to be an unsigned integer
type, so it cannot be `int'.
Um, no. In C you need not cast void pointers.

Um, yes you do, if you want truly portable code.

Martin
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/
Nov 14 '05 #25
whatever...
"Martin Dickopp" <ex****************@zero-based.org> wrote in message
news:cu*************@zero-based.org...
"Chris Fogelklou" <ch*************@comhem.se> writes:
That's not the prototype for malloc. It's

void *malloc(size_t size);

It's irrelevant to the answer, and normally size_t is an int anyway.

No. According to 7.17#2, `size_t' is required to be an unsigned integer
type, so it cannot be `int'.
Um, no. In C you need not cast void pointers.

Um, yes you do, if you want truly portable code.

Martin
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/

Nov 14 '05 #26
whatever...
"Martin Dickopp" <ex****************@zero-based.org> wrote in message
news:cu*************@zero-based.org...
"Chris Fogelklou" <ch*************@comhem.se> writes:
That's not the prototype for malloc. It's

void *malloc(size_t size);

It's irrelevant to the answer, and normally size_t is an int anyway.

No. According to 7.17#2, `size_t' is required to be an unsigned integer
type, so it cannot be `int'.
Um, no. In C you need not cast void pointers.

Um, yes you do, if you want truly portable code.

Martin
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/

Nov 14 '05 #27
Chris Fogelklou wrote:
> Anyone know why engineers get such a bad reputation for being antisocial? > Instead of wasting my time berating you for being a "stupid windows user" > I'll answer the question...

And even at that you failed.

Hmmm... thanks.

You are most certainly welcome.
That's not the prototype for malloc. It's

void *malloc(size_t size);

It's irrelevant to the answer, and normally size_t is an int anyway. I
could have said it's a size_t, but it might have created more problems
than it solved for the question-asker.

Um first off, no "size_t" isn't int. I'd think if anything it would be
"unsigned" not just an int. Anyways the type is size_t. Why bother
replying with "seemingly useful facts" if you're just going to mess with
them?
> So, you get a void pointer in return... you need to cast it to
> something useable, like your matrix, for instance...

Um, no. In C you need not cast void pointers.

Um, yes you do, if you want truly portable code.

No, no you don't. The C standards [C90, C99] don't require you to cast a
void pointer to any other pointer type. If you're code is supposed to work
in C++ as well then maybe. However, putting the cast in can mask a more
serious problem that you forget to include stdlib.h.
> //Allocate memory for matrix and store in pointer. Cast so compiler
> doesn't puke.
> my_matrix_t *pmatrix = (my_matrix_t *)malloc(sizeof(my_matrix_t));

If your compiler pukes at that (without the cast) then you need a new
compiler.

Alright... Do you want to write one up for our embedded system? There
have two compilers, one based on GCC, and neither of them like it if you
equate two pointer types to each other without casting.

Um dude I've coded for embedded platforms before [from 8085, AVR, 68xx
series to the ARM based boards] and in all cases I've never casted a void
pointer to something.

In particular for the ARM boards you can use GCC and it will accept the
non-cast code just fine.

Me thinks you might want to preface your responses with "I used casts cuz my
non-standard compiler asked me to". This is afterall comp.lang.c and we're
not talking about "vendor lang c"
This isn't dynamic though [hint: read the OPs question] it's always 20x20

This is true, but I got the impression that he had no idea how to use
malloc. I was trying to solve his confusion relating to malloc itself.

Point him to the manual pages. Why bother answering his question with code?
How the hell do you think all these "coders" get out there? They take an
ounce of knowledge and spread it so thin to get a job....

If the dude can't learn from a manual page [or googling on the net] then too

Tom
Nov 14 '05 #28
Chris Fogelklou wrote:
> Anyone know why engineers get such a bad reputation for being antisocial? > Instead of wasting my time berating you for being a "stupid windows user" > I'll answer the question...

And even at that you failed.

Hmmm... thanks.

You are most certainly welcome.
That's not the prototype for malloc. It's

void *malloc(size_t size);

It's irrelevant to the answer, and normally size_t is an int anyway. I
could have said it's a size_t, but it might have created more problems
than it solved for the question-asker.

Um first off, no "size_t" isn't int. I'd think if anything it would be
"unsigned" not just an int. Anyways the type is size_t. Why bother
replying with "seemingly useful facts" if you're just going to mess with
them?
> So, you get a void pointer in return... you need to cast it to
> something useable, like your matrix, for instance...

Um, no. In C you need not cast void pointers.

Um, yes you do, if you want truly portable code.

No, no you don't. The C standards [C90, C99] don't require you to cast a
void pointer to any other pointer type. If you're code is supposed to work
in C++ as well then maybe. However, putting the cast in can mask a more
serious problem that you forget to include stdlib.h.
> //Allocate memory for matrix and store in pointer. Cast so compiler
> doesn't puke.
> my_matrix_t *pmatrix = (my_matrix_t *)malloc(sizeof(my_matrix_t));

If your compiler pukes at that (without the cast) then you need a new
compiler.

Alright... Do you want to write one up for our embedded system? There
have two compilers, one based on GCC, and neither of them like it if you
equate two pointer types to each other without casting.

Um dude I've coded for embedded platforms before [from 8085, AVR, 68xx
series to the ARM based boards] and in all cases I've never casted a void
pointer to something.

In particular for the ARM boards you can use GCC and it will accept the
non-cast code just fine.

Me thinks you might want to preface your responses with "I used casts cuz my
non-standard compiler asked me to". This is afterall comp.lang.c and we're
not talking about "vendor lang c"
This isn't dynamic though [hint: read the OPs question] it's always 20x20

This is true, but I got the impression that he had no idea how to use
malloc. I was trying to solve his confusion relating to malloc itself.

Point him to the manual pages. Why bother answering his question with code?
How the hell do you think all these "coders" get out there? They take an
ounce of knowledge and spread it so thin to get a job....

If the dude can't learn from a manual page [or googling on the net] then too

Tom
Nov 14 '05 #29
Chris Fogelklou wrote:
whatever...

Yeah, don't let "the facts" stand in the way of an otherwise poor attempt at
a rant.... ;-)

Tom
Nov 14 '05 #30
Chris Fogelklou wrote:
whatever...

Yeah, don't let "the facts" stand in the way of an otherwise poor attempt at
a rant.... ;-)

Tom
Nov 14 '05 #31
I used casts cuz my non-standard compiler asked me to :)

Anyway... I regret answering now. Please refer to man malloc for more
assistance.

Done.

"Tom St Denis" <to*@securescience.net> wrote in message
news:Hl**************@news04.bloor.is.net.cable.ro gers.com...
Chris Fogelklou wrote:
> Anyone know why engineers get such a bad reputation for being antisocial?
> Instead of wasting my time berating you for being a "stupid windows

user"

And even at that you failed.

Hmmm... thanks.

You are most certainly welcome.
That's not the prototype for malloc. It's

void *malloc(size_t size);

It's irrelevant to the answer, and normally size_t is an int anyway. I
could have said it's a size_t, but it might have created more problems
than it solved for the question-asker.

Um first off, no "size_t" isn't int. I'd think if anything it would be
"unsigned" not just an int. Anyways the type is size_t. Why bother
replying with "seemingly useful facts" if you're just going to mess with
them?
> So, you get a void pointer in return... you need to cast it to
> something useable, like your matrix, for instance...

Um, no. In C you need not cast void pointers.

Um, yes you do, if you want truly portable code.

No, no you don't. The C standards [C90, C99] don't require you to cast a
void pointer to any other pointer type. If you're code is supposed to

work in C++ as well then maybe. However, putting the cast in can mask a more
serious problem that you forget to include stdlib.h.
> //Allocate memory for matrix and store in pointer. Cast so compiler
> doesn't puke.
> my_matrix_t *pmatrix = (my_matrix_t *)malloc(sizeof(my_matrix_t));

If your compiler pukes at that (without the cast) then you need a new
compiler.
Alright... Do you want to write one up for our embedded system? There
have two compilers, one based on GCC, and neither of them like it if you
equate two pointer types to each other without casting.

Um dude I've coded for embedded platforms before [from 8085, AVR, 68xx
series to the ARM based boards] and in all cases I've never casted a void
pointer to something.

In particular for the ARM boards you can use GCC and it will accept the
non-cast code just fine.

Me thinks you might want to preface your responses with "I used casts cuz

my non-standard compiler asked me to". This is afterall comp.lang.c and we're not talking about "vendor lang c"
This isn't dynamic though [hint: read the OPs question] it's always
20x20 This is true, but I got the impression that he had no idea how to use
malloc. I was trying to solve his confusion relating to malloc itself.
Point him to the manual pages. Why bother answering his question with

code? How the hell do you think all these "coders" get out there? They take an
ounce of knowledge and spread it so thin to get a job....

If the dude can't learn from a manual page [or googling on the net] then too F'ing bad.

Tom

Nov 14 '05 #32
I used casts cuz my non-standard compiler asked me to :)

Anyway... I regret answering now. Please refer to man malloc for more
assistance.

Done.

"Tom St Denis" <to*@securescience.net> wrote in message
news:Hl**************@news04.bloor.is.net.cable.ro gers.com...
Chris Fogelklou wrote:
> Anyone know why engineers get such a bad reputation for being antisocial?
> Instead of wasting my time berating you for being a "stupid windows

user"

And even at that you failed.

Hmmm... thanks.

You are most certainly welcome.
That's not the prototype for malloc. It's

void *malloc(size_t size);

It's irrelevant to the answer, and normally size_t is an int anyway. I
could have said it's a size_t, but it might have created more problems
than it solved for the question-asker.

Um first off, no "size_t" isn't int. I'd think if anything it would be
"unsigned" not just an int. Anyways the type is size_t. Why bother
replying with "seemingly useful facts" if you're just going to mess with
them?
> So, you get a void pointer in return... you need to cast it to
> something useable, like your matrix, for instance...

Um, no. In C you need not cast void pointers.

Um, yes you do, if you want truly portable code.

No, no you don't. The C standards [C90, C99] don't require you to cast a
void pointer to any other pointer type. If you're code is supposed to

work in C++ as well then maybe. However, putting the cast in can mask a more
serious problem that you forget to include stdlib.h.
> //Allocate memory for matrix and store in pointer. Cast so compiler
> doesn't puke.
> my_matrix_t *pmatrix = (my_matrix_t *)malloc(sizeof(my_matrix_t));

If your compiler pukes at that (without the cast) then you need a new
compiler.
Alright... Do you want to write one up for our embedded system? There
have two compilers, one based on GCC, and neither of them like it if you
equate two pointer types to each other without casting.

Um dude I've coded for embedded platforms before [from 8085, AVR, 68xx
series to the ARM based boards] and in all cases I've never casted a void
pointer to something.

In particular for the ARM boards you can use GCC and it will accept the
non-cast code just fine.

Me thinks you might want to preface your responses with "I used casts cuz

my non-standard compiler asked me to". This is afterall comp.lang.c and we're not talking about "vendor lang c"
This isn't dynamic though [hint: read the OPs question] it's always
20x20 This is true, but I got the impression that he had no idea how to use
malloc. I was trying to solve his confusion relating to malloc itself.
Point him to the manual pages. Why bother answering his question with

code? How the hell do you think all these "coders" get out there? They take an
ounce of knowledge and spread it so thin to get a job....

If the dude can't learn from a manual page [or googling on the net] then too F'ing bad.

Tom

Nov 14 '05 #33
Chris Fogelklou wrote:
That's not the prototype for malloc. It's

void *malloc(size_t size);

It's irrelevant to the answer, and normally size_t is an int anyway.

size_t can be many things. But it is never int. Never.
I
could have said it's a size_t, but it might have created more problems than
You could have said that size_t is just an unsigned integer.

So, you get a void pointer in return... you need to cast it to something
useable, like your matrix, for instance...
Um, no. In C you need not cast void pointers.

Um, yes you do, if you want truly portable code.

Let me quote Tom St Denis on this one:

"Um, no. In C you need not cast void pointers." Before you even attempt
to contradict me go look up the vast amount of discussion on this
topic right here in this newsgroup. If you can come up with an argument

//Allocate memory for matrix and store in pointer. Cast so compiler
doesn't puke.
my_matrix_t *pmatrix = (my_matrix_t *)malloc(sizeof(my_matrix_t));
If your compiler pukes at that (without the cast) then you need a new
compiler.

Alright... Do you want to write one up for our embedded system?

If your compiler requires a cast from pointer to void to a pointer to
any other object type then it is broken. Why, because it will not
accept all strictly conforming C programs (for stand alone
implementations).
There have
two compilers, one based on GCC, and neither of them like it if you equate
two pointer types to each other without casting.

In the following T and S can not be void.

If you have a pointer to S and a pointer to T then you need the cast
to assign one to the other AND you need to know that they are
compatable. A pointer to void can be implicitly converted to any
pointer type, no cast required.

--
Thomas.

Nov 14 '05 #34
Chris Fogelklou wrote:
That's not the prototype for malloc. It's

void *malloc(size_t size);

It's irrelevant to the answer, and normally size_t is an int anyway.

size_t can be many things. But it is never int. Never.
I
could have said it's a size_t, but it might have created more problems than
You could have said that size_t is just an unsigned integer.

So, you get a void pointer in return... you need to cast it to something
useable, like your matrix, for instance...
Um, no. In C you need not cast void pointers.

Um, yes you do, if you want truly portable code.

Let me quote Tom St Denis on this one:

"Um, no. In C you need not cast void pointers." Before you even attempt
to contradict me go look up the vast amount of discussion on this
topic right here in this newsgroup. If you can come up with an argument

//Allocate memory for matrix and store in pointer. Cast so compiler
doesn't puke.
my_matrix_t *pmatrix = (my_matrix_t *)malloc(sizeof(my_matrix_t));
If your compiler pukes at that (without the cast) then you need a new
compiler.

Alright... Do you want to write one up for our embedded system?

If your compiler requires a cast from pointer to void to a pointer to
any other object type then it is broken. Why, because it will not
accept all strictly conforming C programs (for stand alone
implementations).
There have
two compilers, one based on GCC, and neither of them like it if you equate
two pointer types to each other without casting.

In the following T and S can not be void.

If you have a pointer to S and a pointer to T then you need the cast
to assign one to the other AND you need to know that they are
compatable. A pointer to void can be implicitly converted to any
pointer type, no cast required.

--
Thomas.

Nov 14 '05 #35
Hi Thomas,

Yes, I was wrong about the int. It should definitely an unsigned int. I
wrote my response very quickly and obviously didn't pull up my handy C
library help file when I did it. I just took offense to the "higher than
thou" attitude to a question that was out-and-out stated to be a homework
assignment by a beginner.

I was trying to express how to use malloc. Thinking that malloc takes an
int would probably not affect the application code in any way (and yes I
know that ints have a smaller maximum absolute value do to their signedness,
but think about what would really happen... hint... compiler casting from
positive int to unsigned int... before you catch me on this one, although I
do expect someone to respond in any case.)

As long as he isn't writing his own malloc function, don't you think I still
might have provided some handy, if perhaps a bit imprecise, advice?

That said, apparently the embedded compilers I've been using are broken. I
have a cross platform environment going here, and when building for win32,
casting a void * to anything else is OK. But when I move to the embedded
version, it breaks. I am referring only to my firsthand experience.

Cheers,
Chris

PS. Next time I write anything in this NG, I'll ensure that I have a
complete bibliography appended to the bottom and that I triple check every
fact stated with the latest ANSI standards and their addendums.

"Thomas Stegen" <ts*****@cis.strath.ac.uk> wrote in message
news:40********@nntphost.cis.strath.ac.uk...
Chris Fogelklou wrote:
That's not the prototype for malloc. It's

void *malloc(size_t size);

It's irrelevant to the answer, and normally size_t is an int anyway.

size_t can be many things. But it is never int. Never.
I
could have said it's a size_t, but it might have created more problems than it solved for the question-asker.

You could have said that size_t is just an unsigned integer.

So, you get a void pointer in return... you need to cast it to somethinguseable, like your matrix, for instance...

Um, no. In C you need not cast void pointers.

Um, yes you do, if you want truly portable code.

Let me quote Tom St Denis on this one:

"Um, no. In C you need not cast void pointers." Before you even attempt
to contradict me go look up the vast amount of discussion on this
topic right here in this newsgroup. If you can come up with an argument

//Allocate memory for matrix and store in pointer. Cast so compiler
doesn't puke.
my_matrix_t *pmatrix = (my_matrix_t *)malloc(sizeof(my_matrix_t));

If your compiler pukes at that (without the cast) then you need a new
compiler.

Alright... Do you want to write one up for our embedded system?

If your compiler requires a cast from pointer to void to a pointer to
any other object type then it is broken. Why, because it will not
accept all strictly conforming C programs (for stand alone
implementations).
There have
two compilers, one based on GCC, and neither of them like it if you equate two pointer types to each other without casting.

In the following T and S can not be void.

If you have a pointer to S and a pointer to T then you need the cast
to assign one to the other AND you need to know that they are
compatable. A pointer to void can be implicitly converted to any
pointer type, no cast required.

--
Thomas.

Nov 14 '05 #36
Hi Thomas,

Yes, I was wrong about the int. It should definitely an unsigned int. I
wrote my response very quickly and obviously didn't pull up my handy C
library help file when I did it. I just took offense to the "higher than
thou" attitude to a question that was out-and-out stated to be a homework
assignment by a beginner.

I was trying to express how to use malloc. Thinking that malloc takes an
int would probably not affect the application code in any way (and yes I
know that ints have a smaller maximum absolute value do to their signedness,
but think about what would really happen... hint... compiler casting from
positive int to unsigned int... before you catch me on this one, although I
do expect someone to respond in any case.)

As long as he isn't writing his own malloc function, don't you think I still
might have provided some handy, if perhaps a bit imprecise, advice?

That said, apparently the embedded compilers I've been using are broken. I
have a cross platform environment going here, and when building for win32,
casting a void * to anything else is OK. But when I move to the embedded
version, it breaks. I am referring only to my firsthand experience.

Cheers,
Chris

PS. Next time I write anything in this NG, I'll ensure that I have a
complete bibliography appended to the bottom and that I triple check every
fact stated with the latest ANSI standards and their addendums.

"Thomas Stegen" <ts*****@cis.strath.ac.uk> wrote in message
news:40********@nntphost.cis.strath.ac.uk...
Chris Fogelklou wrote:
That's not the prototype for malloc. It's

void *malloc(size_t size);

It's irrelevant to the answer, and normally size_t is an int anyway.

size_t can be many things. But it is never int. Never.
I
could have said it's a size_t, but it might have created more problems than it solved for the question-asker.

You could have said that size_t is just an unsigned integer.

So, you get a void pointer in return... you need to cast it to somethinguseable, like your matrix, for instance...

Um, no. In C you need not cast void pointers.

Um, yes you do, if you want truly portable code.

Let me quote Tom St Denis on this one:

"Um, no. In C you need not cast void pointers." Before you even attempt
to contradict me go look up the vast amount of discussion on this
topic right here in this newsgroup. If you can come up with an argument

//Allocate memory for matrix and store in pointer. Cast so compiler
doesn't puke.
my_matrix_t *pmatrix = (my_matrix_t *)malloc(sizeof(my_matrix_t));

If your compiler pukes at that (without the cast) then you need a new
compiler.

Alright... Do you want to write one up for our embedded system?

If your compiler requires a cast from pointer to void to a pointer to
any other object type then it is broken. Why, because it will not
accept all strictly conforming C programs (for stand alone
implementations).
There have
two compilers, one based on GCC, and neither of them like it if you equate two pointer types to each other without casting.

In the following T and S can not be void.

If you have a pointer to S and a pointer to T then you need the cast
to assign one to the other AND you need to know that they are
compatable. A pointer to void can be implicitly converted to any
pointer type, no cast required.

--
Thomas.

Nov 14 '05 #37
"Chris Fogelklou" <ch*************@comhem.se> writes:
Yes, I was wrong about the int. It should definitely an unsigned int.
Actually, the standard only requires `size_t' to be an unsigned integer
type. Sometimes it is `unsigned int', sometimes it is another unsigned
integer type.
That said, apparently the embedded compilers I've been using are broken. I
have a cross platform environment going here, and when building for win32,
casting a void * to anything else is OK. But when I move to the embedded
version, it breaks. I am referring only to my firsthand experience.
When `malloc' works on some systems and doesn't on others, that is often
an indication of incorrect code. A typical error of this kind is to use
`malloc' without a proper declaration in scope (which one usually gets
by including <stdlib.h>). Usually, the compiler would warn you if use
`malloc' and haven't included <stdlib.h>, but by casting the return
value, the warning is suppressed. Despite the lack of a warning, the
code is still incorrect and will break on some systems.
PS. Next time I write anything in this NG, I'll ensure that I have a
complete bibliography appended to the bottom and that I triple check
every fact stated with the latest ANSI standards and their addendums.

The latter is certainly a good idea. That's what I do unless I'm very
sure. (I still make mistakes sometimes, but fortunately, someone else
will reply and point them out very quickly, so it's not a problem.)

Martin
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/
Nov 14 '05 #38
"Chris Fogelklou" <ch*************@comhem.se> writes:
Yes, I was wrong about the int. It should definitely an unsigned int.
Actually, the standard only requires `size_t' to be an unsigned integer
type. Sometimes it is `unsigned int', sometimes it is another unsigned
integer type.
That said, apparently the embedded compilers I've been using are broken. I
have a cross platform environment going here, and when building for win32,
casting a void * to anything else is OK. But when I move to the embedded
version, it breaks. I am referring only to my firsthand experience.
When `malloc' works on some systems and doesn't on others, that is often
an indication of incorrect code. A typical error of this kind is to use
`malloc' without a proper declaration in scope (which one usually gets
by including <stdlib.h>). Usually, the compiler would warn you if use
`malloc' and haven't included <stdlib.h>, but by casting the return
value, the warning is suppressed. Despite the lack of a warning, the
code is still incorrect and will break on some systems.
PS. Next time I write anything in this NG, I'll ensure that I have a
complete bibliography appended to the bottom and that I triple check
every fact stated with the latest ANSI standards and their addendums.

The latter is certainly a good idea. That's what I do unless I'm very
sure. (I still make mistakes sometimes, but fortunately, someone else
will reply and point them out very quickly, so it's not a problem.)

Martin
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/
Nov 14 '05 #39
Thanks for your pleasant and reasonable feedback ;-)
Usually, the compiler would warn you if use
`malloc' and haven't included <stdlib.h>, but by casting the return
value, the warning is suppressed. Despite the lack of a warning, the
code is still incorrect and will break on some systems.
As I said, I always do this cast to make my code work. From firsthand
experience, I have in fact made the mistake of forgetting stdlib.h. At
least in my case, the compiler gives a "function with no prototype" warning
and the linker pukes. This is because the cast refers only to the return
value from the function, not the function itself (it must still resolve
malloc in order to cast its return value to something, right?). Even if it
did hide the compiler warning, wouldn't the build break because the linker
wouldn not be able to resolve the malloc label?

Chris

PS: Disobeying my previous own advice to refer to the ANSI specs... :)

"Martin Dickopp" <ex****************@zero-based.org> wrote in message
news:cu*************@zero-based.org...
"Chris Fogelklou" <ch*************@comhem.se> writes:
Yes, I was wrong about the int. It should definitely an unsigned int.

Actually, the standard only requires `size_t' to be an unsigned integer
type. Sometimes it is `unsigned int', sometimes it is another unsigned
integer type.
That said, apparently the embedded compilers I've been using are broken.

I have a cross platform environment going here, and when building for win32, casting a void * to anything else is OK. But when I move to the embedded version, it breaks. I am referring only to my firsthand experience.

When `malloc' works on some systems and doesn't on others, that is often
an indication of incorrect code. A typical error of this kind is to use
`malloc' without a proper declaration in scope (which one usually gets
by including <stdlib.h>). Usually, the compiler would warn you if use
`malloc' and haven't included <stdlib.h>, but by casting the return
value, the warning is suppressed. Despite the lack of a warning, the
code is still incorrect and will break on some systems.
PS. Next time I write anything in this NG, I'll ensure that I have a
complete bibliography appended to the bottom and that I triple check
every fact stated with the latest ANSI standards and their addendums.

The latter is certainly a good idea. That's what I do unless I'm very
sure. (I still make mistakes sometimes, but fortunately, someone else
will reply and point them out very quickly, so it's not a problem.)

Martin
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/

Nov 14 '05 #40
Thanks for your pleasant and reasonable feedback ;-)
Usually, the compiler would warn you if use
`malloc' and haven't included <stdlib.h>, but by casting the return
value, the warning is suppressed. Despite the lack of a warning, the
code is still incorrect and will break on some systems.
As I said, I always do this cast to make my code work. From firsthand
experience, I have in fact made the mistake of forgetting stdlib.h. At
least in my case, the compiler gives a "function with no prototype" warning
and the linker pukes. This is because the cast refers only to the return
value from the function, not the function itself (it must still resolve
malloc in order to cast its return value to something, right?). Even if it
did hide the compiler warning, wouldn't the build break because the linker
wouldn not be able to resolve the malloc label?

Chris

PS: Disobeying my previous own advice to refer to the ANSI specs... :)

"Martin Dickopp" <ex****************@zero-based.org> wrote in message
news:cu*************@zero-based.org...
"Chris Fogelklou" <ch*************@comhem.se> writes:
Yes, I was wrong about the int. It should definitely an unsigned int.

Actually, the standard only requires `size_t' to be an unsigned integer
type. Sometimes it is `unsigned int', sometimes it is another unsigned
integer type.
That said, apparently the embedded compilers I've been using are broken.

I have a cross platform environment going here, and when building for win32, casting a void * to anything else is OK. But when I move to the embedded version, it breaks. I am referring only to my firsthand experience.

When `malloc' works on some systems and doesn't on others, that is often
an indication of incorrect code. A typical error of this kind is to use
`malloc' without a proper declaration in scope (which one usually gets
by including <stdlib.h>). Usually, the compiler would warn you if use
`malloc' and haven't included <stdlib.h>, but by casting the return
value, the warning is suppressed. Despite the lack of a warning, the
code is still incorrect and will break on some systems.
PS. Next time I write anything in this NG, I'll ensure that I have a
complete bibliography appended to the bottom and that I triple check
every fact stated with the latest ANSI standards and their addendums.

The latter is certainly a good idea. That's what I do unless I'm very
sure. (I still make mistakes sometimes, but fortunately, someone else
will reply and point them out very quickly, so it's not a problem.)

Martin
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/

Nov 14 '05 #41
Chris Fogelklou wrote:
Thanks for your pleasant and reasonable feedback ;-)

Usually, the compiler would warn you if use
`malloc' and haven't included <stdlib.h>, but by casting the return
value, the warning is suppressed. Despite the lack of a warning, the
code is still incorrect and will break on some systems.

As I said, I always do this cast to make my code work.

You are sure you aren't using some sort of C++ compiler? C++ does
require the cast. If so, maybe there is some way of forcing C mode
on it...
From firsthand
experience, I have in fact made the mistake of forgetting stdlib.h. At
least in my case, the compiler gives a "function with no prototype" warning
This is a good thing.
This is because the cast refers only to the return
value from the function, not the function itself
Right.
(it must still resolve
malloc in order to cast its return value to something, right?).
That depends on what you mean by resolve. In the C89 standard (which is
the standard that is most widely implemented) an unprototyped function
defaults to returning int and casting an int to a pointer is valid
although implementation defined. C99 "fixed" this by requiring
prototypes. C99 got that one right in my opinion.
Even if it
did hide the compiler warning, wouldn't the build break because the linker
wouldn not be able to resolve the malloc label?

That depends on the linker and compiler. Some linkers only look at
the function name at the point of call and links in a function with
the same name in the loaded libraries, others might in some way require
the function to be prototyped (however that is implemented).

It is important to note that header files are only part of the
libraries. The actual functions do not reside in them, more often
they sit about in different files and are totally oblivious to

--
Thomas.

Nov 14 '05 #42
Chris Fogelklou wrote:
Thanks for your pleasant and reasonable feedback ;-)

Usually, the compiler would warn you if use
`malloc' and haven't included <stdlib.h>, but by casting the return
value, the warning is suppressed. Despite the lack of a warning, the
code is still incorrect and will break on some systems.

As I said, I always do this cast to make my code work.

You are sure you aren't using some sort of C++ compiler? C++ does
require the cast. If so, maybe there is some way of forcing C mode
on it...
From firsthand
experience, I have in fact made the mistake of forgetting stdlib.h. At
least in my case, the compiler gives a "function with no prototype" warning
This is a good thing.
This is because the cast refers only to the return
value from the function, not the function itself
Right.
(it must still resolve
malloc in order to cast its return value to something, right?).
That depends on what you mean by resolve. In the C89 standard (which is
the standard that is most widely implemented) an unprototyped function
defaults to returning int and casting an int to a pointer is valid
although implementation defined. C99 "fixed" this by requiring
prototypes. C99 got that one right in my opinion.
Even if it
did hide the compiler warning, wouldn't the build break because the linker
wouldn not be able to resolve the malloc label?

That depends on the linker and compiler. Some linkers only look at
the function name at the point of call and links in a function with
the same name in the loaded libraries, others might in some way require
the function to be prototyped (however that is implemented).

It is important to note that header files are only part of the
libraries. The actual functions do not reside in them, more often
they sit about in different files and are totally oblivious to

--
Thomas.

Nov 14 '05 #43
Chris Fogelklou wrote:
Thanks for your pleasant and reasonable feedback ;-)
Usually, the compiler would warn you if use
`malloc' and haven't included <stdlib.h>, but by casting the return
value, the warning is suppressed. Despite the lack of a warning, the
code is still incorrect and will break on some systems.

As I said, I always do this cast to make my code work.

It doesn't. If the code works with the cast, it'll work without it, too.
From firsthand
experience, I have in fact made the mistake of forgetting stdlib.h.
The correct fix is to include it. Casting merely hides the problem instead
of fixing it.
At
least in my case, the compiler gives a "function with no prototype"
warning
And the correct fix is to give a prototype, by including <stdlib.h>
and the linker pukes. This is because the cast refers only to the return
value from the function, not the function itself (it must still resolve
malloc in order to cast its return value to something, right?). Even if
it did hide the compiler warning, wouldn't the build break because the
linker wouldn not be able to resolve the malloc label?

No, in a typical implementation the malloc code will be tucked away in the
standard library, and the linker will find it just fine. You have
misunderstood the problem.

Here's an example of how failing to #include <stdlib.h> can cause problems.
Consider an implementation with pointer registers and integer registers,
which are kept very, very separate.

The malloc binary, which is already compiled and is tucked safely away in a
library, populates a pointer register.

Code which calls malloc but which fails to #include <stdlib.h> forces the
compiler to assume that malloc returns int. So our hypothetical
implementation generates code to call malloc and then to fetch an int from
- yes, the integer register. This is not the value malloc actually
returned! It's just whatever junk was in that register.

Since, "to get it to compile", we had to cast the call, the compiler doesn't
object when we then shove that random int into a pointer.

Result: a nasty bug, and quite hard to track down.

Of course, your compiler might not do things that way (or in some other way
that also shows up your incorrect code). With your compiler, the code might
even "work" as you expected. And you might be content with that. But one
day, if your program is actually useful, you'll want to port your code to
another platform, and another compiler.....

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 14 '05 #44
Chris Fogelklou wrote:
Thanks for your pleasant and reasonable feedback ;-)
Usually, the compiler would warn you if use
`malloc' and haven't included <stdlib.h>, but by casting the return
value, the warning is suppressed. Despite the lack of a warning, the
code is still incorrect and will break on some systems.

As I said, I always do this cast to make my code work.

It doesn't. If the code works with the cast, it'll work without it, too.
From firsthand
experience, I have in fact made the mistake of forgetting stdlib.h.
The correct fix is to include it. Casting merely hides the problem instead
of fixing it.
At
least in my case, the compiler gives a "function with no prototype"
warning
And the correct fix is to give a prototype, by including <stdlib.h>
and the linker pukes. This is because the cast refers only to the return
value from the function, not the function itself (it must still resolve
malloc in order to cast its return value to something, right?). Even if
it did hide the compiler warning, wouldn't the build break because the
linker wouldn not be able to resolve the malloc label?

No, in a typical implementation the malloc code will be tucked away in the
standard library, and the linker will find it just fine. You have
misunderstood the problem.

Here's an example of how failing to #include <stdlib.h> can cause problems.
Consider an implementation with pointer registers and integer registers,
which are kept very, very separate.

The malloc binary, which is already compiled and is tucked safely away in a
library, populates a pointer register.

Code which calls malloc but which fails to #include <stdlib.h> forces the
compiler to assume that malloc returns int. So our hypothetical
implementation generates code to call malloc and then to fetch an int from
- yes, the integer register. This is not the value malloc actually
returned! It's just whatever junk was in that register.

Since, "to get it to compile", we had to cast the call, the compiler doesn't
object when we then shove that random int into a pointer.

Result: a nasty bug, and quite hard to track down.

Of course, your compiler might not do things that way (or in some other way
that also shows up your incorrect code). With your compiler, the code might
even "work" as you expected. And you might be content with that. But one
day, if your program is actually useful, you'll want to port your code to
another platform, and another compiler.....

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 14 '05 #45
>Chris Fogelklou wrote:
... I always [have to] do this cast to make my code work [on one
particular compiler]

In article <40********@nntphost.cis.strath.ac.uk>,
Thomas Stegen <ts*****@cis.strath.ac.uk> wrote:You are sure you aren't using some sort of C++ compiler? C++ does
require the cast. If so, maybe there is some way of forcing C mode
on it...

This is possible, but at least equally-likely is that the embedded
system compiler he mentioned is just broken (or, more accurate if
less punchy than the Anglo-Saxon-verb version, "fails to conform to
one of the ANSI/ISO C standards" :-) ).

A lot of embedded-system "C compilers" have, historically, been
quite awful. The widespread use of GCC has, I think, succeeded at
"raising the bar" here: if you have a lousy embedded-system compiler
suite for target CPU "X", you need only to port the GNU Compiler
Collection to target X, and you now have a half-decent compiler
suite. (Not that porting GCC is easy, but it is a lot easier than
writing an entire compiler from scratch.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
Reading email is like searching for food in the garbage, thanks to spammers.
Nov 14 '05 #46
>Chris Fogelklou wrote:
... I always [have to] do this cast to make my code work [on one
particular compiler]

In article <40********@nntphost.cis.strath.ac.uk>,
Thomas Stegen <ts*****@cis.strath.ac.uk> wrote:You are sure you aren't using some sort of C++ compiler? C++ does
require the cast. If so, maybe there is some way of forcing C mode
on it...

This is possible, but at least equally-likely is that the embedded
system compiler he mentioned is just broken (or, more accurate if
less punchy than the Anglo-Saxon-verb version, "fails to conform to
one of the ANSI/ISO C standards" :-) ).

A lot of embedded-system "C compilers" have, historically, been
quite awful. The widespread use of GCC has, I think, succeeded at
"raising the bar" here: if you have a lousy embedded-system compiler
suite for target CPU "X", you need only to port the GNU Compiler
Collection to target X, and you now have a half-decent compiler
suite. (Not that porting GCC is easy, but it is a lot easier than
writing an entire compiler from scratch.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
Reading email is like searching for food in the garbage, thanks to spammers.
Nov 14 '05 #47
Hi Richard,
It doesn't. If the code works with the cast, it'll work without it, too.
I concede... I just checked and I don't actually have a compiler now that
craps out without the cast. I could swear that I have used one that would
fail without the cast, so I have just always casted... and never turned
back.
The correct fix is to include it. Casting merely hides the problem instead
of fixing it.
I have not disagreed with this, however, cast or no cast.
And the correct fix is to give a prototype, by including <stdlib.h>

Ditto.
Nov 14 '05 #48
Hi Richard,
It doesn't. If the code works with the cast, it'll work without it, too.
I concede... I just checked and I don't actually have a compiler now that
craps out without the cast. I could swear that I have used one that would
fail without the cast, so I have just always casted... and never turned
back.
The correct fix is to include it. Casting merely hides the problem instead
of fixing it.
I have not disagreed with this, however, cast or no cast.
And the correct fix is to give a prototype, by including <stdlib.h>

Ditto.
Nov 14 '05 #49
Joona I Palaste wrote:
Tom St Denis <to*@securescience.net> scribbled the following:
Joona I Palaste wrote:
.... snip ...

What makes you so sure Knady is working on a UNIX system?

Who cares if he isn't? Stupid windows users can trap themselves
in ignorance for all I care. As for me and my Gentoo'd box I'll
go hug my manual pages now... ;-)

And what about stupid UNIX users? Oh, right. I forgot. To be able
to so much as boot up a UNIX machine you have to be both a
hardware and a software high wizard. How silly of me. =)
Windows users. I don't like Microsoft any more than you do, but
that's no excuse to prejudice against their entire userbase.

^^^^^^^^^^^^^^^^^^^^

You, and Knady, should be aware that Tom is a pubescent
opinionated Ottawa teen-ager with all the diplomatic skills of Dan
Pop and very little of Dans knowledge nor Dans capability at the
English language. Toms invective level appears to be improving,
so he escapes replonking since he changed his 'from' description.

BTW, the above phrase could be either "for prejudice against" or
"to prejudge". As it stands it is highly confusing.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.