Problem with malloc

[Knady]

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

[CBFalconer]

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!

[CBFalconer]

Chris Fogelklou wrote:

.... snip ...

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.

You are misusing it, especially if one is based on gcc. You NEVER
should cast a void pointer being assigned to another pointer
type. Errors from such statements usually indicate a failure to
have proper prototypes for malloc, caused by failure to #include
stdlib.h, or failure to use a C compiler, often caused by naming
source files with a .C or .cpp extension. The best statement for
the malloc call above is:

my_matrix_t *pmatrix = malloc(sizeof *pmatrix);

Casts are automatically suspect code. (double)95.34152718% of
them are unnecessary and serve only to conceal errors.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[CBFalconer]

Chris Fogelklou wrote:

.... snip ...

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.

You are misusing it, especially if one is based on gcc. You NEVER
should cast a void pointer being assigned to another pointer
type. Errors from such statements usually indicate a failure to
have proper prototypes for malloc, caused by failure to #include
stdlib.h, or failure to use a C compiler, often caused by naming
source files with a .C or .cpp extension. The best statement for
the malloc call above is:

my_matrix_t *pmatrix = malloc(sizeof *pmatrix);

Casts are automatically suspect code. (double)95.34152718% of
them are unnecessary and serve only to conceal errors.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[CBFalconer]

Chris Fogelklou wrote:

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

A wise decision around here. Getting a copy of the C standard (or
N869) is also advisable. Otherwise you will soon die the death of
a thousand pecks. Remember, the vultures are circling :-)

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[CBFalconer]

Chris Fogelklou wrote:

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

A wise decision around here. Getting a copy of the C standard (or
N869) is also advisable. Otherwise you will soon die the death of
a thousand pecks. Remember, the vultures are circling :-)

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Emmanuel Delahaye]

In 'comp.lang.c', "Chris Fogelklou" <ch*************@comhem.se> wrote:

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.

You've got it. This NG has a reputation of excellence. Trust me, you'll learn
*a lot* by reading it.

--
-ed- em**********@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=cpp
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

[Emmanuel Delahaye]

In 'comp.lang.c', "Chris Fogelklou" <ch*************@comhem.se> wrote:

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.

You've got it. This NG has a reputation of excellence. Trust me, you'll learn
*a lot* by reading it.

--
-ed- em**********@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?lib=cpp
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/

[Richard Heathfield]

CBFalconer wrote:

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.

This is, quite simply, not true.

IIRC, Tom is 21 years old.

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

[Richard Heathfield]

CBFalconer wrote:

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.

This is, quite simply, not true.

IIRC, Tom is 21 years old.

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

[Keith Thompson]

"Chris Fogelklou" <ch*************@comhem.se> writes:

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.

Turn back now. 8-)}

Perhaps you were using a C++ compiler. C++, unlike C, doesn't
implicitly convert void* to other pointer types, and C++ is close
enough to being a superset of C that you can probably compile most C
code using a C++ compiler with only a few tweaks.

But it almost always makes more sense to compile your C code with a C
compiler, and your C++ code with a C++ compiler. (Most C++ compilers
either ship with a C compiler, or can be invoked as a C compiler.)
<OT>It seldom makes sense to use malloc() in C++; use the "new"
operator instead.</OT>

In rare circumstances, it can make sense to write code that's valid C
and valid C++; such code will probably need to cast the result of
malloc(). If you don't already know why you'd need to do this, you
almost certainly shouldn't try.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

[Keith Thompson]

"Chris Fogelklou" <ch*************@comhem.se> writes:

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.

Turn back now. 8-)}

Perhaps you were using a C++ compiler. C++, unlike C, doesn't
implicitly convert void* to other pointer types, and C++ is close
enough to being a superset of C that you can probably compile most C
code using a C++ compiler with only a few tweaks.

But it almost always makes more sense to compile your C code with a C
compiler, and your C++ code with a C++ compiler. (Most C++ compilers
either ship with a C compiler, or can be invoked as a C compiler.)
<OT>It seldom makes sense to use malloc() in C++; use the "new"
operator instead.</OT>

In rare circumstances, it can make sense to write code that's valid C
and valid C++; such code will probably need to cast the result of
malloc(). If you don't already know why you'd need to do this, you
almost certainly shouldn't try.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

[Keith Thompson]

"Chris Fogelklou" <ch*************@comhem.se> writes:

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.

The argument to malloc is of type size_t, the same type as the result
of the sizeof operator. size_t is guaranteed to be an unsigned
integer type, but it needn't be unsigned int; in many implementations,
it's unsigned long.

That's exactly why "size_t" exists, so you don't have to know which of
the predefined unsigned integer types to use for a given implementation.

One more thing: please don't top-post. The convention here in
comp.lang.c is for your response to *follow* any quoted text from the
previous article, which should be limited to what's directly relevant
to your response (as I've done here). It may not seem like a big
deal, but it really does make it easier for your readers.

A: Because it makes your article more difficult to read.
Q: Why is top-posting bad?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

[Keith Thompson]

"Chris Fogelklou" <ch*************@comhem.se> writes:

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.

The argument to malloc is of type size_t, the same type as the result
of the sizeof operator. size_t is guaranteed to be an unsigned
integer type, but it needn't be unsigned int; in many implementations,
it's unsigned long.

That's exactly why "size_t" exists, so you don't have to know which of
the predefined unsigned integer types to use for a given implementation.

One more thing: please don't top-post. The convention here in
comp.lang.c is for your response to *follow* any quoted text from the
previous article, which should be limited to what's directly relevant
to your response (as I've done here). It may not seem like a big
deal, but it really does make it easier for your readers.

A: Because it makes your article more difficult to read.
Q: Why is top-posting bad?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

[Dan Pop]

In <c4*********@news1.newsguy.com> Chris Torek <no****@torek.net> writes:

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

I'm not sure how feasible this approach is when target X is a small
microprocessor or microcontroller. IIRC, GCC was designed with the 68000
CPU as the minimal target processor.

Furthermore, many embedded control CPUs have specific features that need
C extensions in order to be used, e.g. the bit addressing of the 8051
family or the on chip vs extern RAM or ROM.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <c4*********@news1.newsguy.com> Chris Torek <no****@torek.net> writes:

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

I'm not sure how feasible this approach is when target X is a small
microprocessor or microcontroller. IIRC, GCC was designed with the 68000
CPU as the minimal target processor.

Furthermore, many embedded control CPUs have specific features that need
C extensions in order to be used, e.g. the bit addressing of the 8051
family or the on chip vs extern RAM or ROM.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[those who know me have no need of my name]

[though i've not set follow-up's this is off-topic for clc and i hope the
next round will move to e-mail, comp.arch.embedded or the gcc mailing-list]

in comp.lang.c i read:

I'm not sure how feasible this approach is when target X is a small
microprocessor or microcontroller. IIRC, GCC was designed with the 68000
CPU as the minimal target processor.
gcc currently supports arc, arm, avr, cris, ip2022, iq2000, m32r, mc68hc1[12],
embedded ppc and xtensa mcu's and embedded platforms, and even dsp's, e.g.,
ti's tms320c[34]x series.
Furthermore, many embedded control CPUs have specific features that need
C extensions in order to be used, e.g. the bit addressing of the 8051
family or the on chip vs extern RAM or ROM.

indeed, that would be part of the challenge. perhaps it would be too hard
for some platforms, but it can be a solution for some.

--
a signature

[those who know me have no need of my name]

[though i've not set follow-up's this is off-topic for clc and i hope the
next round will move to e-mail, comp.arch.embedded or the gcc mailing-list]

in comp.lang.c i read:

I'm not sure how feasible this approach is when target X is a small
microprocessor or microcontroller. IIRC, GCC was designed with the 68000
CPU as the minimal target processor.
gcc currently supports arc, arm, avr, cris, ip2022, iq2000, m32r, mc68hc1[12],
embedded ppc and xtensa mcu's and embedded platforms, and even dsp's, e.g.,
ti's tms320c[34]x series.
Furthermore, many embedded control CPUs have specific features that need
C extensions in order to be used, e.g. the bit addressing of the 8051
family or the on chip vs extern RAM or ROM.

indeed, that would be part of the challenge. perhaps it would be too hard
for some platforms, but it can be a solution for some.

--
a signature