Hello,

I am a completely newbie in C. I have a question about the function
malloc(), hope somebody can help me.

Method 1 :
/* allocate memory for a 100 character string */
char *str;
str = malloc(100 * sizeof(char));

Method 2:
/* allocate memory for a 100 character string */
char *str;
str = (char *) malloc(100 * sizeof(char));

My question is why do i need to include (char *) to allocate memory,
as method 1 can also do the job. I 've checked some book, they said
malloc() returns  a pointer to the allocated block of memeory,
therefore why do we need to include (char *) in the statement?

Sorry for my poor english.
Thank you.

Allen

ICQ: 8805558

Another remark:
  malloc(100 * sizeof(char)) is the same as malloc(100) because
  sizeof(char) is 1 (per definition, this has been mentioned very often in
c.l.c)

Anyway: typecasts like the one you placed before malloc() in method-2 don't
  perform any action (no code is generated for them), they just supress
  compiler-warnings. Usually method-1 is the better choice, because
  in malloc.h you'll find malloc() being defined as a function returning
'void *'.
  Assigning a 'void *' to a 'char *' is legal without warning.

Regards Rainer

  str = malloc (100);

But don't worry about this if you're not happy with it; your version is
perfectly OK, and there's time enough for the niceties later.

The question is why you think you need it.  If your compiler is spitting
out the program without the (char *) -- which is, by the way, known as a
cast -- then check you really are invoking it as a C compiler, not as a
C++ compiler.  In particular make sure your source file is called
something.c rather than something.cpp or anything else.

If that's OK, make sure you are including <stdlib.h>.  If this doesn't
help either, post a short complete program and the error messages and
I'm sure somebody will be able to help.

If you've read a book or seen some code where the cast is used, then the
best advice is just to ignore it.  There was once a time when the cast
was necessary, but with the current language definition, it isn't.  Some
people are still stuck in old habits or concerned about portability to
older compilers.

Cheers,
Richard
--
Richard Stamp
Churchill College, Cambridge

Cheers,
Richard
--
Richard Stamp
Churchill College, Cambridge

|Hello,
|
|I am a completely newbie in C. I have a question about the function
|malloc(), hope somebody can help me.
|
|Method 1 :
|/* allocate memory for a 100 character string */
|char *str;
|str = malloc(100 * sizeof(char));
|
|Method 2:
|/* allocate memory for a 100 character string */
|char *str;
|str = (char *) malloc(100 * sizeof(char));

Both of the above contain the text `* sizeof(char)'.  Since, by
definition, sizeof(char) == 1, this is unnecessary.  OTOH, suppose
the elements of str might be some wider type than char.  This
is quite possible when code is internationalized, for example.
Now
    str = malloc(100);    /* or str = malloc(100*sizeof(char)); */
will not do.  A safer approach is
    str = malloc(100 * sizeof *str);
This still contains the {*filter*} hardwared constant 100.  I'm
sure you can find a way to make it go away.

|My question is why do i need to include (char *) to allocate memory,

You don't, as long as your programming language is C.
The problem is that in C
    str = malloc(100 * stizeof *str);
is good style and the cast is poor style, in
C++, the cast is required.  OTOH, in C++ the use
of malloc is frowned on, so it should be a non-issue.

|as method 1 can also do the job. I 've checked some book, they said
|malloc() returns  a pointer to the allocated block of memeory,
|therefore why do we need to include (char *) in the statement?

The main effect of the (char *) is to mask the failure to
#include <stdlib.h>
This masking is a bad thing, so the cast is also a bad thing.

<snip>
|Method-1 and Method-2 do exactly the same...
|may be you didn't
|  #include <malloc.h>
|so the Compiler assumes that malloc() is a function returning int.

Since <malloc.h> is not a standard header (and usually represents
older non-standard approaches), it is a GoodIdea(TM) to
never #include it.  But #include <stdlib.h> is called for.

...

...

--
-----------------------------------------


-----------------------------------------

[SNIP]

Just a few small points.

Firstly, char may be more than one byte in size on other platforms. It
may even contain more than an octet of bits per byte ! The Standard
only states at least the range -127 to 127 should be supported.It may
very well be more. Therefore you should not assert that 'sizeof(char)
== 1' is always true.Secondly, the original poster allocated room for
a 100 character strings.However, he neglected to also allocate room
for the nul char i.e. instead of

char str = malloc(sizeof(char)*100);

he should have written something like this.

char str = malloc(sizeof(char)*(100 + 1));

On a style note, try to use a symbolic constant, rather than a
literal. For example, the way below has two advantages. Firstly,
there is a strong semantic connection between the amount of
memory being allocated and its intended use. Secondly, if later
in the program you decide to support strings of another length,
you simply change the value of one preprocessor directive, rather
than making manual adjustments in your translation unit.

#define STRSZ 100
char str = malloc(sizeof(char)*(STRSZ + 1));

Thirdly, note that if you use fgets() to read your string, you may need
to specify an extra character, because fgets() also reads in the newline
character, if any. Finally, you must ALWAYS check the return value from
malloc(). The code as written, makes an assumption that the memory
request was valid.For example, you could have written

#define STRSZ 100

int main(void){
  char str = malloc(sizeof(char)*(STRSZ + 2));
  if( str == NULL )
    exit( EXIT_FAILURE );
  return EXIT_SUCCESS;

What do you think sizeof() reports?  Size in... octets?  Why would
you care, and what if you can't measure the size of a 12-bit object
in 8-bit octets?

-s
--

C/Unix wizard, Pro-commerce radical, Spam fighter.  Boycott Spamazon!
Not speaking for my employer.  Questions on C/Unix?  Send mail for help.
Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!

The reason this causes confusion is that there are (at least) three
conflicting definitions for "byte".

(a) The Standard defines "byte" to mean (I'm abstracting a bit, but this
    is basically right) "the size of a variable of type 'char'".  I'll
    call this a "Standard byte".

(b) Many people use the word "byte" to mean "the smallest addressable
    unit on the architecture in question".  I'll call this a "machine
    byte".

(c) And the majority of people, of course, just use "byte" to mean
    "eight bits".  I'll call that an "octet".

Now, sizeof() yields the size of its operand in Standard bytes.  So,
sizeof(char) is always 1.  As you correctly observe, the minimum
range of 'char' means this must correspond to at least an octet, but
it could reasonably be more.

For example, perhaps we're dealing with some kind of extended character
set and we want to be able to hold a larger range of character codes
in a 'char'.  So the length of a 'char' increases, and so does the
length of a Standard byte.  Of course, this doesn't affect the size
of the machine byte.  If the smallest addressable unit is 8 bits, we
could quite reasonably end up with one Standard byte equal to two
machine bytes or more.

Coming at it the other way, suppose the machine byte is 64 bits
(I understand this is the case with some RISC processors).  Now, the
implementor has a choice to make: either make a 'char', and hence
the Standard byte, 64 bits (which is quite legal but a little odd),
or leave it at 8 bits (say) and do some sort of unpacking where
necessary.  Then, we end up with a Standard byte being smaller than
a machine byte.

It's just a terminology thing.

Cheers,
Richard
--
Richard Stamp
Churchill College, Cambridge

[SNIP]

Whoops !
Scarab Damage Control Team take over...

#include <stdlib.h>
#define STRSZ 100

int main(void){
  char str = malloc(sizeof(char)*(STRSZ+2));
  if(str == NULL)
    exit(EXIT_FAILURE);

  /* use str */

  if(str != NULL)
    free(str);

  return EXIT_SUCCESS;

|Firstly, char may be more than one byte in size on other platforms.

Does no one read the standard any more before claiming to be an
expert?  We are talking about C here.  Your fantasies don't count.
Start with the definition of byte (3.4), the definition of char (6.1.2.5),
and of sizeof (6.3.3.4)

| It
|may even contain more than an octet of bits per byte ! The Standard
|only states at least the range -127 to 127 should be supported.It may
|very well be more. Therefore you should not assert that 'sizeof(char)
|== 1' is always true.

I understand that you are getting the ISO committees to accept
you amendation to the standard, which in the discussion of sizeof
in 6.3.3.4 states:
"When applied to an operand that has type char, unsigned char, or
signed char, (or a qualified version thereof) the result is 1."

If this flat statement in the standard is in error, you should quickly
let all the C implementors share your insight.

Note: If you ever switch to C++, then you will need the cast because
void pointers cannot be implicitly converted to other types.  It does
not hide any errors since you MUST include <stdlib.h> to avoid errors.

--

I believe we can change anything.
I believe in my dream.
    - Joe Satriani

===================================
#include <stdlib.h>
#define STRSZ 100

int main(void){
  char str = malloc(sizeof(char)*(STRSZ+2));
  if(str == NULL)
    exit(EXIT_FAILURE);

  /* use str */

  if(str != NULL)
    free(str);

  return EXIT_SUCCESS;

My remarks:

* sizeof(char) is _always_ one.
* Why STRSZ + 2?  It only takes one character to hold '\0'.
* That should be char *str =..., not char str = ...
* Since you exited if str was null, the check prior to free() is not needed.
* Since this code is in main(), is there any reason to exit(EXIT_FAILURE)
instead of return EXIT_FAILURE?

Please reply publicly or disregard the e-mail address in the header.  Use
'syd' at the commercial internet service provider Netroplex instead.
Thanks.