malloc() for struct member

[googler]

Hello, I have a very simple question that I'm a bit confused about
right now. Is it OK to allocate memory by malloc() or calloc() for a
struct member and then call free() on it? For example, I have the code
below.

struct mystruct {
int a;
char *b;
int c;
};

struct mystruct myobject;

myobject.b = (char *)malloc(50);
....
....
free(myobject.b);

Is the above code OK, or is there any potential problem with it?

Thanks!

[Keith Thompson]

"googler" <pi********@yahoo.com> writes:

Hello, I have a very simple question that I'm a bit confused about
right now. Is it OK to allocate memory by malloc() or calloc() for a
struct member and then call free() on it? For example, I have the code
below.

struct mystruct {
int a;
char *b;
int c;
};

struct mystruct myobject;

myobject.b = (char *)malloc(50);
...
...
free(myobject.b);

Is the above code OK, or is there any potential problem with it?

The only problem I can see is that you cast the result of malloc().
This is legal but unnecessary, and can mask errors. Change the line
to

myobject.b = malloc(50);

Other than that, I don't see anything wrong.

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

[Barry Schwarz]

On 5 Oct 2005 20:06:15 -0700, "googler" <pi********@yahoo.com> wrote:

Hello, I have a very simple question that I'm a bit confused about
right now. Is it OK to allocate memory by malloc() or calloc() for a
struct member and then call free() on it? For example, I have the code
below.

struct mystruct {
int a;
char *b;
int c;
};

struct mystruct myobject;

myobject.b = (char *)malloc(50);
Don't cast the return from malloc. It doesn't help and may cause the
compiler to suppress a diagnostic you really want to see....
...
free(myobject.b);
This is how you would avoid a memory leak. What prompted the
question?

Is the above code OK, or is there any potential problem with it?

Thanks!

<<Remove the del for email>>

[googler]

> What prompted the question?

A code like the one I gave resulted in a crash. That's why I posted the
question. My main point was if allocating and freeing memory is OK when
done on a struct member (I knew it's OK, but the above crash made me a
bit confused).

I presume it's a compilation problem since the release build works and
the crash happens for debug build (which is weird since it is usually
the other way round).

[Alex Fraser]

"googler" <pi********@yahoo.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...
[snip]

I presume it's a compilation problem since the release build works and
the crash happens for debug build (which is weird since it is usually
the other way round).

I agree it is usually the other way round, but the same still applies: the
difference is most likely due to undefined behaviour.

Alex

[Flash Gordon]

Alex Fraser wrote:

"googler" <pi********@yahoo.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...
[snip]

I presume it's a compilation problem since the release build works and
the crash happens for debug build (which is weird since it is usually
the other way round).

I agree it is usually the other way round, but the same still applies: the
difference is most likely due to undefined behaviour.

To expand on what Alex said (which I agree with), I would strongly
suggest that you track down and fix the bug. It might not be causing a
crash in the release build, but it could well be corrupting something
under some conditions leading to incorrect results, for example raising
millions of invoices for 139.90 instead of 149.90 and loosing some
company lots of money. Or you might be lucky and it crashes on your
customers instead of corrupting their vital data.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[KJ]

googler wrote:

Hello, I have a very simple question that I'm a bit confused about
right now. Is it OK to allocate memory by malloc() or calloc() for a
struct member and then call free() on it? For example, I have the code
below.

struct mystruct {
int a;
char *b;
int c;
};

struct mystruct myobject;

myobject.b = (char *)malloc(50); As Every Body Said Not Need To Type Cast. ...
...
free(myobject.b);

Is the above code OK, or is there any potential problem with it? The code doesn't seems to have problem. But since i m not sure the
whole code is there or not so it could be some other reason.
Thanks!

[Kenneth Brody]

googler wrote:

Hello, I have a very simple question that I'm a bit confused about
right now. Is it OK to allocate memory by malloc() or calloc() for a
struct member and then call free() on it? For example, I have the code
below.

struct mystruct {
int a;
char *b;
int c;
};

struct mystruct myobject;

myobject.b = (char *)malloc(50);
...
...
free(myobject.b);

Is the above code OK, or is there any potential problem with it?

The above is no different than:

char *b;
...
b = malloc(50);
...
free(b);

(Aside from the removal of the unnecessary, and sometimes problematic,
cast of malloc's return.)

The fact that the place you store the pointer is within a struct has
no bearing on how malloc/free work.

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[googler]

Thanks everybody for the help.

myobject.b = (char *)malloc(50);

As Every Body Said Not Need To Type Cast.

Doesn't K&R use type cast with malloc()? Maybe it's not a good
practice, but I'm wondering that in almost all C codes I've seen, type
cast has been used with malloc().

[Keith Thompson]

"googler" <pi********@yahoo.com> writes:

Thanks everybody for the help.

> myobject.b = (char *)malloc(50);

As Every Body Said Not Need To Type Cast.

Doesn't K&R use type cast with malloc()? Maybe it's not a good
practice, but I'm wondering that in almost all C codes I've seen, type
cast has been used with malloc().

Yes, but the errata list at
<http://cm.bell-labs.com/cm/cs/cbook/2ediffs.html> corrects it:

142(6.5, toward the end): The remark about casting the return
value of malloc ("the proper method is to declare ... then
explicitly coerce") needs to be rewritten. The example is correct
and works, but the advice is debatable in the context of the
1988-1989 ANSI/ISO standards. It's not necessary (given that
coercion of void * to ALMOSTANYTYPE * is automatic), and possibly
harmful if malloc, or a proxy for it, fails to be declared as
returning void *. The explicit cast can cover up an unintended
error. On the other hand, pre-ANSI, the cast was necessary, and it
is in C++ also.

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

[Baxter]

After you free the memory, set the member variable to NULL and see if that
changes anything.

When you start getting weird errors/crashes, it's usually worthwhile to look
for buffer overruns, freeing memory that has already been freed, and things
like that.

--
---------------------------------------------------------------------
DataGet & PocketLog www.dataget.com
Data Collectors www.baxcode.com
--------------------------------------------------------------------

"googler" <pi********@yahoo.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...

What prompted the question?

A code like the one I gave resulted in a crash. That's why I posted the
question. My main point was if allocating and freeing memory is OK when
done on a struct member (I knew it's OK, but the above crash made me a
bit confused).

I presume it's a compilation problem since the release build works and
the crash happens for debug build (which is weird since it is usually
the other way round).