473,381 Members | 1,555 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,381 software developers and data experts.

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 3166
Knady 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.


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
Knady 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.


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:
Knady 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.

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:
Knady 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.

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:
Knady 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:
Knady 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:
Knady 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.

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:
Knady 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.

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

"Knady" <please@_do_not_spam.com> wrote in message

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

"Knady" <please@_do_not_spam.com> wrote in message

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


Knady 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.
Thx


The faq is a good source for help on multidimensional array dynamic
allocations. The link:

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


Knady 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.
Thx


The faq is a good source for help on multidimensional array dynamic
allocations. The link:

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"
I'll answer the question...

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));
"Knady" <please@_do_not_spam.com> wrote in message
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"
I'll answer the question...

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));
"Knady" <please@_do_not_spam.com> wrote in message
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"
I'll answer the question...
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"
I'll answer the question...
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:
Knady 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.
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. =)
Anyway, I hope you are kidding about your attitude towards Windows
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:
Knady 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.
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. =)
Anyway, I hope you are kidding about your attitude towards Windows
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:
Knady 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.

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. =)
Anyway, I hope you are kidding about your attitude towards Windows
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:
Knady 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.

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. =)
Anyway, I hope you are kidding about your attitude towards Windows
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
it solved for the question-asker.
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
it solved for the question-asker.
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.


Chapter and verse, please?

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.


Chapter and verse, please?

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.


Chapter and verse, please?

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.


Chapter and verse, please?

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
F'ing bad.

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
F'ing bad.

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"
> 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 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"
> 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 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
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 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
not already proffered please do so.

//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.

For more information read section 6.3.2.3 of the C99 standard.

--
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
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 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
not already proffered please do so.

//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.

For more information read section 6.3.2.3 of the C99 standard.

--
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
not already proffered please do so.

//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.

For more information read section 6.3.2.3 of the C99 standard.

--
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
not already proffered please do so.

//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.

For more information read section 6.3.2.3 of the C99 standard.

--
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?

Thanks in advance!

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?

Thanks in advance!

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
and the linker pukes.
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
any headers, included or not.

--
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
and the linker pukes.
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
any headers, included or not.

--
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
email: forget about it http://web.torek.net/torek/index.html
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
email: forget about it http://web.torek.net/torek/index.html
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. =)
Anyway, I hope you are kidding about your attitude towards
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.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 14 '05 #50

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

33
by: Knady | last post by:
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...
37
by: Patrik Huber | last post by:
Hello! I got the following Code in Assembler (NASM), which prints out "5" in realmode: mov ax, 0xB800 mov es, ax mov byte , '5' I want to do the same in gcc now, but I'm stuck. GCC...
8
by: Snis Pilbor | last post by:
First, let me announce that this is very possibly off-topic because malloc is a specific third party accessory to c, etc. I spent about an hour trying to find a more appropriate newsgroup and...
3
by: ferbar | last post by:
Hi all, I'm working on a program that tests a random number generator -rand()- in this case. Runs and Chi square test have to be applied to see if the numbers generated are random.. anyway, I'm...
3
by: Sean Shanny | last post by:
To all, We are running postgresql 7.4.1 on an G5 with dual procs, OSX 10.3.3 server, 8GB mem, attached to a fully configured 3.5TB XRaid box via fibre channel. I think we have run into this...
39
by: Martin Jørgensen | last post by:
Hi, I'm relatively new with C-programming and even though I've read about pointers and arrays many times, it's a topic that is a little confusing to me - at least at this moment: ---- 1)...
9
by: Me | last post by:
Hi, I ran into a malloc problem but I can't find the solution. I try to read a file into a variable with malloc like this: BYTE *lcdata; lcdata = malloc(fsize*sizeof(BYTE));
21
by: softwindow | last post by:
#include "stdio.h" #include "malloc.h" struct student{ int age; char *nms; struct student *next; }; struct student *create(){ int ags=0,size=sizeof(struct student); char *nms=" ";
87
by: pereges | last post by:
I have a C program which I created on Windows machine. I have compiled and executed the program on windows machine and it gives me the consistent output every time i run it. for eg. input a = 2,...
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...
0
by: ryjfgjl | last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
0
by: aa123db | last post by:
Variable and constants Use var or let for variables and const fror constants. Var foo ='bar'; Let foo ='bar';const baz ='bar'; Functions function $name$ ($parameters$) { } ...
0
by: ryjfgjl | last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
0
by: ryjfgjl | last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
1
by: nemocccc | last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
1
by: Sonnysonu | last post by:
This is the data of csv file 1 2 3 1 2 3 1 2 3 1 2 3 2 3 2 3 3 the lengths should be different i have to store the data by column-wise with in the specific length. suppose the i have to...
0
by: Hystou | last post by:
There are some requirements for setting up RAID: 1. The motherboard and BIOS support RAID configuration. 2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.