IS this a proper way of freeing memory with free()

[Raman]

Hi All,

Here is a small Code,

int main(void)
{
char *p=(char *) malloc(100);
strcpy(p,"Test1 234567890");
p=p+10;
free(p);
/*** Is here a memory Leak, because p is now
pointing 10 location past to the start of allocated memory
****/

/** some stuff with p again**/


}
Thanks and Regards,
Raman Chalotra

[Ian Collins]

Richard Heathfield wrote:

Ian Collins said:

>>Richard Heathfield wrote:

>>>Ian Collins said:

Richard Heathfield wrote:

>Yevgen Muntyan said:
>
>>It's easy to write lot of C code which is valid C++. You have to
>>apply casts to return value of malloc though.
>
>It's *pointless* to write lots of C code which is valid C++. [...]

It's not pointless if you are using C++ for hardware simulations to
test your C drivers.

If you're using C++ for the hardware simulations, you're using C++,
not C.

The driver code is C.

Fine, in which case it isn't C++, so you don't need the cast on malloc.

I'm not sure if you are being deliberately obtuse.

My point is there is sometimes value in having C code which is valid
C++. The driver code in question is compiled as C for the embedded
target, but compiled with the host C++ compiler for testing in a
hardware simulator.

So the code in question is written in the subset of C that is valid C++.

--
Ian Collins.

[Richard Heathfield]

Ian Collins said:

Richard Heathfield wrote:

>Ian Collins said:

>>>Richard Heathfield wrote:

If you're using C++ for the hardware simulations, you're using C++,
not C.

The driver code is C.

Fine, in which case it isn't C++, so you don't need the cast on
malloc.

I'm not sure if you are being deliberately obtuse.

No, I'm usually pretty acute.

My point is there is sometimes value in having C code which is valid
C++. The driver code in question is compiled as C for the embedded
target, but compiled with the host C++ compiler for testing in a
hardware simulator.

Not wise, in my opinion. Your test environment does not adequately
reflect your production environment. You wouldn't try to pull that
stunt with Perl on the target and COBOL on the simulator, would you? So
why do it with C and C++?

So the code in question is written in the subset of C that is valid
C++.

With identical semantics? Are you *sure*? And once you've answered in
the affirmative, ask yourself whether you are *really* sure.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Ian Collins]

Richard Heathfield wrote:

Ian Collins said:

>>Richard Heathfield wrote:

>>>
Fine, in which case it isn't C++, so you don't need the cast on
malloc.

I'm not sure if you are being deliberately obtuse.

No, I'm usually pretty acute.

I had noticed...

>>My point is there is sometimes value in having C code which is valid
C++. The driver code in question is compiled as C for the embedded
target, but compiled with the host C++ compiler for testing in a
hardware simulator.

Not wise, in my opinion. Your test environment does not adequately
reflect your production environment.

The value gained form being able to test drivers or a complete embedded
system off the target. We built up a very accurate simulation of the
micro we were using which enabled us to fully test our software before
we had hardware.

>
You wouldn't try to pull that
stunt with Perl on the target and COBOL on the simulator, would you? So
why do it with C and C++?

Is there a common subset of Perl and COBOL?

>

>>So the code in question is written in the subset of C that is valid
C++.

With identical semantics? Are you *sure*? And once you've answered in
the affirmative, ask yourself whether you are *really* sure.

Yes, and we back that up with acceptance tests that run against the
simulation and the final product.

--
Ian Collins.

[Christopher Layne]

Ian Collins wrote:

I'm not sure if you are being deliberately obtuse.

My point is there is sometimes value in having C code which is valid
C++. The driver code in question is compiled as C for the embedded
target, but compiled with the host C++ compiler for testing in a
hardware simulator.

So the code in question is written in the subset of C that is valid C++.

Why not just compile them both under C mode?

[Ian Collins]

Christopher Layne wrote:

Ian Collins wrote:

>>I'm not sure if you are being deliberately obtuse.

My point is there is sometimes value in having C code which is valid
C++. The driver code in question is compiled as C for the embedded
target, but compiled with the host C++ compiler for testing in a
hardware simulator.

So the code in question is written in the subset of C that is valid C++.

Why not just compile them both under C mode?

The simulation uses C++ for things like hardware registers. In C mode,
a register is a typedef for the appropriate unsigned integer type. In
C++ mode, it can be a class object with conversion and assignment
operators that trigger state changes in the simulation when the register
is written or read.

--
Ian Collins.

[Stephen Sprunk]

"Ian Collins" <ia******@hotma il.comwrote in message
news:53******** ******@mid.indi vidual.net...

Richard Heathfield wrote:

>Yevgen Muntyan said:

>>>It's easy to write lot of C code which is valid C++. You have to
apply casts to return value of malloc though.

It's *pointless* to write lots of C code which is valid C++. If you
can't take advantage of C++'s non-C features, why bother using it?
And
if you can, then it's not compilable in C. And malloc makes for bad
C++
programs, on the whole.

It's not pointless if you are using C++ for hardware simulations to
test
your C drivers.

But you're _not_ testing your C drivers, you're testing
similar-but-not-identical C++ drivers.

Even if your code uses the common subset syntax-wise, you may
accidentally use constructs that mean different (but equally valid)
things in the two languages, e.g. const, or run into compiler
optimization differences.

C++ provides a simple and convenient mechanism for mixing in C objects.
Why not use it and avoid the potential pitfalls?

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
--
Posted via a free Usenet account from http://www.teranews.com

[Keith Thompson]

Yevgen Muntyan <mu************ ****@tamu.eduwr ites:

Christopher Layne wrote:

>Yevgen Muntyan wrote:

>>>>#define FOO_NEW() ((Foo*) malloc (sizeof (Foo))) // *must* cast here
No. It's not. It's not clear, it's obtuse and pointless monkeying that
*reduces* visible intent.
What do you do if you need to replace malloc() with another allocator?
Grep? While this macro is indeed stupid, it was an example of where
cast is needed.
*If* you write a macro which allocates a Foo structure (this macro can
do arbitrary nice or complex things, and there *are* macros like that
in real code) you better make it of type Foo*.

Yevgen

What are you NOT getting about the fact that the cast is not needed
in ISO C?
Do you know the purpose and characteristics of void pointers?

You're not kidding, are you? I said *I need* cast because I want a safer
expression. If I apply cast, the expression acquires a type.

((Type*) malloc (sizeof (Type)))

Ok, I can *sort of* see your point here. Without the cast, the
expression is of type void*, which will be implicitly converted to any
pointer-to-object type. It's less safe in the sense that if you apply
sizeof to the wrong thing, the compiler won't warn you about it:

(A):
double *p1;
int *p2;
p1 = malloc(sizeof *p2);

Whereas if you use the type, then getting the type wrong will give you
a constraint error and a required diagnostic:

(B):
double *p1;
int *p2;
p1 = (int*)malloc(si zeof(int)); /* Compiler catches error */

But if you have the correct type in the cast, but the wrong type in
the sizeof argument, you're back to another error that the compiler
won't catch:

(C):
double *p1;
int *p2;
p1 = (double*)malloc (sizeof(int));

What you're doing is basically case (B) with the two occurrences of
the type name kept in synch by using a macro.

But if you want to use a macro, why not apply the same technique to
case (A), giving you just as much safety?

(D):
#define NEW_OBJ(ptr) ((ptr) = malloc(sizeof *(ptr)))
#define NEW_ARR(ptr, count) ((ptr) = malloc(count * sizeof *(ptr)))

double *p1;
int *p2;
NEW_OBJ(p1);
if (p1 == NULL) {
/* allocation failed */
}
NEW_ARR(p2, 10);
if (p2 == NULL) {
/* allocation failed */
}

Personally, I'm content to keep the sizeof argument consistent
manually, but you can use macros to do this for you *without* using
unnecessary casts.

--
Keith Thompson (The_Other_Keit h) 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.

[Ian Collins]

Stephen Sprunk wrote:

"Ian Collins" <ia******@hotma il.comwrote in message
news:53******** ******@mid.indi vidual.net...

>>
It's not pointless if you are using C++ for hardware simulations to test
your C drivers.

But you're _not_ testing your C drivers, you're testing
similar-but-not-identical C++ drivers.

You could argue the same for any off-target testing. The generated code
is different. The logic remains the same.

Even if your code uses the common subset syntax-wise, you may
accidentally use constructs that mean different (but equally valid)
things in the two languages, e.g. const, or run into compiler
optimization differences.

I've been using this technique for fifteen years or so, using the same
evolving set of tools, so I know the differences between the two and how
to avoid them. I've even checked the assembler output for various bits
of code compiled with the C and C++ compilers.

The advantages of developing and debugging the drivers on a host rather
then a target environment (less these days than a decade ago) still
outweighs any risks. As I said elsethread, I always use automated
acceptance tests that run on both the target and the simulation. Host
based simulations aren't a replacement for target testing, but they can
be a replacement for target debugging.

C++ provides a simple and convenient mechanism for mixing in C objects.
Why not use it and avoid the potential pitfalls?

The code under test is C and I abhor conditional compilation for testing
in source files.

--
Ian Collins.

[Stephen Sprunk]

"Yevgen Muntyan" <mu************ ****@tamu.eduwr ote in message
news:eq******** **@news.tamu.ed u...

Indeed, code tends to break when you don't touch it. You
put cast in, it explodes in two months.

Bit rot is a very real phenomenon, though Murphy's Law states that your
code won't explode until you're doing a demo for an important customer.

What you're all saying is why it's not a good idea to
use cast. And that's indeed true, it's not a good idea
to cast when you don't have to. What's not true
is that any given piece of code with cast is wrong and
dangerous in any situation.

It's not guaranteed to be wrong. However, casting hides the cases where
it _is_ wrong, and not casting exposes that. Coding so that you expose
bugs, not hide them, is good practice.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
--
Posted via a free Usenet account from http://www.teranews.com

[Keith Thompson]

Ian Collins <ia******@hotma il.comwrites:
[...]

My point is there is sometimes value in having C code which is valid
C++. The driver code in question is compiled as C for the embedded
target, but compiled with the host C++ compiler for testing in a
hardware simulator.

So the code in question is written in the subset of C that is valid C++.

Interesting.

You need your drivers to be callable from C++ on the host system, so
you write them to be compilable as either C or C++, restricting
yourself to the intersection of the two languages. It seems to me
your requirement is perfectly reasonable, but I'm not convinced you've
found the best solution. Have you considered instead compiling your
drivers as C on the host system, and calling them from C++ using C++'s
'extern "C"' feature? Your headers would still have to be valid as
both C and C++ (possibly using "#ifdef __cplusplus" here and there),
but the actual implementation of the drivers could be pure C.

--
Keith Thompson (The_Other_Keit h) 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.