473,322 Members | 1,421 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,322 software developers and data experts.

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

Hi All,

Here is a small Code,

int main(void)
{
char *p=(char *) malloc(100);
strcpy(p,"Test1234567890");
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

Feb 1 '07
171 4688
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.
Feb 9 '07 #151
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.
Feb 9 '07 #152
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.
Feb 9 '07 #153
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?
Feb 9 '07 #154
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.
Feb 9 '07 #155
"Ian Collins" <ia******@hotmail.comwrote in message
news:53**************@mid.individual.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

Feb 9 '07 #156
Yevgen Muntyan <mu****************@tamu.eduwrites:
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(sizeof(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_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.
Feb 9 '07 #157
Stephen Sprunk wrote:
"Ian Collins" <ia******@hotmail.comwrote in message
news:53**************@mid.individual.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.
Feb 9 '07 #158
"Yevgen Muntyan" <mu****************@tamu.eduwrote in message
news:eq**********@news.tamu.edu...
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

Feb 9 '07 #159
Ian Collins <ia******@hotmail.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_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.
Feb 9 '07 #160
Ian Collins <ia******@hotmail.comwrites:
Richard Heathfield wrote:
>Ian Collins said:
[...]
>>>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.
Acceptance tests can find bugs; they can't prove the absence of bugs.
It's at least conceivable that you have some bug caused by a piece of
code that's legal C and legal C++, but with different semantics, and
that your acceptance tests aren't quite thorough enough to find it.
Consistently compiling your driver code as pure C, as I suggested in
another response in this thread, might avoid such bugs.

I'm not saying that this is likely or arguing that your approach is
wrong, just suggesting a possible improvement to your methodology.
(Or there might be a good reason why you can't do what I suggested.)

--
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.
Feb 9 '07 #161
Keith Thompson wrote:
Ian Collins <ia******@hotmail.comwrites:
>>Richard Heathfield wrote:
>>>Ian Collins said:

[...]
>>>>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.


Acceptance tests can find bugs; they can't prove the absence of bugs.
Nor do I claim that they do. But I will claim that the code developed
in the host environment is better tested that if it had been developed
purely on the embedded target simple because the testing is much easier
and is therefore more rigorous. Some aspects of driver operation are
extremely difficult to unit test consistently on real hardware,
especially if the hardware is deeply embedded.
It's at least conceivable that you have some bug caused by a piece of
code that's legal C and legal C++, but with different semantics, and
that your acceptance tests aren't quite thorough enough to find it.
Consistently compiling your driver code as pure C, as I suggested in
another response in this thread, might avoid such bugs.
I agree. There is also a real chance that one or other of the compiler
have a bug which can lead to behavioural differences. In my experience,
the benefits gained form this approach outweigh the risks.
I'm not saying that this is likely or arguing that your approach is
wrong, just suggesting a possible improvement to your methodology.
(Or there might be a good reason why you can't do what I suggested.)
See may comments of the use of C++ objects for device registers.

--
Ian Collins.
Feb 9 '07 #162
Keith Thompson wrote:
Ian Collins <ia******@hotmail.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.
The problem is the other way round. I want the C code to work directly
with C++ objects (pretend bits of hardware).

--
Ian Collins.
Feb 10 '07 #163
Keith Thompson wrote:
Yevgen Muntyan <mu****************@tamu.eduwrites:
>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(sizeof(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.
Yes, given that (B) is *exactly* quoted
((Type*) malloc (sizeof (Type))).
And (C) is irrelevant (but it adds to that many potential errors I am
going to step onto, yes?)
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)))
Perhaps I want to do

Foo **array;
*array++ = CALLOC_OBJ(Foo);

with CALLOC_OBJ doing calloc(sizeof(Foo), 1) in this case (it's g_new0()
in glib-using code). In any case I don't know why I would want to use
NEW_OBJ(ptr) which modifies ptr just to use The Right (or how people say
"idiomatic in c.l.c") '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.
Of course I can. As well I can avoid using goto, I can have single
return in any function, or (going other direction) I can avoid using
stream methods from stdio.h and use raw open/close/read/write, or...
But why? I have never claimed it's necessary to use casts. I did claim
using casts is nice and most importantly harmless in some situations.
You may not agree with "nice" part but you have to prove yet cast
can harm there.

Keith, please tell, did I claim I can't do without casts? If no,
why do you invent extra macros to demonstrate how I can do that?
I could just use malloc(whatever_is_right_in_c_l_c). If yes,
please quote that.

People again and again tell why I don't have to use cast or something.
I am refusing to follow the advice and then they tell gods will
punish me, and to prove that they show all kinds of errors possible
elsewhere in other situations. Why?
Feb 10 '07 #164
Ian Collins <ia******@hotmail.comwrites:
Keith Thompson wrote:
>Ian Collins <ia******@hotmail.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.
The problem is the other way round. I want the C code to work directly
with C++ objects (pretend bits of hardware).
So, for example, a piece of C code in the driver running on the actual
hardware that says:
*ptr = 42;
will simply write 42 into the specified location -- but since that
location might have some special meaning in the target hardware,
there could be some hardware-specific side effects.

Whereas that same piece of code, compiled as C++, running in the host
emulator, might invoke an overloaded "*" function that emulates the
same side effects.

Is that (an oversimplification of) what's going on, or am I missing
the whole point?

I'm beginning to think that the number of posters who have good
reasons to compile the same code as C and as C++ has increased from 1
to 2.

--
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.
Feb 10 '07 #165
Keith Thompson wrote:
>
So, for example, a piece of C code in the driver running on the actual
hardware that says:
*ptr = 42;
will simply write 42 into the specified location -- but since that
location might have some special meaning in the target hardware,
there could be some hardware-specific side effects.

Whereas that same piece of code, compiled as C++, running in the host
emulator, might invoke an overloaded "*" function that emulates the
same side effects.

Is that (an oversimplification of) what's going on, or am I missing
the whole point?
Yes, that is what's going on.
I'm beginning to think that the number of posters who have good
reasons to compile the same code as C and as C++ has increased from 1
to 2.
:)

--
Ian Collins.
Feb 10 '07 #166
Yevgen Muntyan <mu****************@tamu.eduwrites:
[...]
>Yevgen Muntyan <mu****************@tamu.eduwrites:
[snip]
>>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.
[snip]
Keith, please tell, did I claim I can't do without casts? If no,
why do you invent extra macros to demonstrate how I can do that?
I could just use malloc(whatever_is_right_in_c_l_c). If yes,
please quote that.
You didn't say in so many words that you "can't do without casts", but
you did say, in so many words, that you "need" casts. In fact, you
don't *need* to use casts.
People again and again tell why I don't have to use cast or something.
I am refusing to follow the advice and then they tell gods will
punish me, and to prove that they show all kinds of errors possible
elsewhere in other situations. Why?
I've never claimed the gods will punish you, so I can't answer that.
I do question your claim that adding a cast can make for a "safer
expression". The expression (the result of malloc()) has a type,
namely void*. (Admittedly void* is in some sense a weaker type than,
say, foo*.) It acquires another type whether you use a cast or not.

But I'm already tired of this thread, even though I've hardly posted
to it, so I don't plan to debate the point any further.

--
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.
Feb 10 '07 #167
Keith Thompson wrote:
Yevgen Muntyan <mu****************@tamu.eduwrites:
[...]
>>Yevgen Muntyan <mu****************@tamu.eduwrites:

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

[snip]
>Keith, please tell, did I claim I can't do without casts? If no,
why do you invent extra macros to demonstrate how I can do that?
I could just use malloc(whatever_is_right_in_c_l_c). If yes,
please quote that.

You didn't say in so many words that you "can't do without casts", but
you did say, in so many words, that you "need" casts. In fact, you
don't *need* to use casts.
*I* do need them because they help *me* avoid stupid bugs.
I might have misused the English word "need", I do not feel
exact sense it carries when I say "I need". I guess "I want"
is better here, but if I used it, it would be immediately
interpreted as I want that cast in the same way as I want
ice cream, without any rational base.
>People again and again tell why I don't have to use cast or something.
I am refusing to follow the advice and then they tell gods will
punish me, and to prove that they show all kinds of errors possible
elsewhere in other situations. Why?

I've never claimed the gods will punish you, so I can't answer that.
You didn't. You just added to the pool of all those errors I
should expect in my code by providing your example (C), even
though that's a type of error which is *impossible* if I use
the macro instead of blind casts here and there (the casts
which I don't use).
I do question your claim that adding a cast can make for a "safer
expression". The expression (the result of malloc()) has a type,
namely void*. (Admittedly void* is in some sense a weaker type than,
say, foo*.) It acquires another type whether you use a cast or not.
Yes, and malloc() is also not blind since it doesn't have eyes.
If you didn't understand what I meant by "typeless", I apologize
for poor wording. I doubt it though.
But I'm already tired of this thread, even though I've hardly posted
to it, so I don't plan to debate the point any further.
You hardly posted, but you did add to collective wisdom's "Wrong.",
didn't you.
Feb 10 '07 #168
Keith Thompson said:
Ian Collins <ia******@hotmail.comwrites:
>Richard Heathfield wrote:
>>Ian Collins said:
[...]
>>>>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.

Acceptance tests can find bugs; they can't prove the absence of bugs.
Whilst I agree with your general line of argument, Keith, I think it
bears mentioning that acceptance tests are generally not intended even
to find bugs (let alone prove their absence, which they can't do anyway
as you rightly say), but rather to determine whether the software as a
whole performs substantially according to its specification: not "is
this program bug-free as far as we can tell?" but "is this program good
enough for our requirements?"

Personally, I'm of the opinion that any bug is one bug too many, but
many people seem to think that they'd rather use the software some time
this side of eternity and are therefore quite happy to put up with the
odd bug.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Feb 10 '07 #169
Richard Heathfield <rj*@see.sig.invalidwrites:
Keith Thompson said:
>Ian Collins <ia******@hotmail.comwrites:
>>Richard Heathfield wrote:
Ian Collins said:
[...]
>>>>>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.

Acceptance tests can find bugs; they can't prove the absence of bugs.

Whilst I agree with your general line of argument, Keith, I think it
bears mentioning that acceptance tests are generally not intended even
to find bugs (let alone prove their absence, which they can't do anyway
as you rightly say), but rather to determine whether the software as a
whole performs substantially according to its specification: not "is
this program bug-free as far as we can tell?" but "is this program good
enough for our requirements?"
It reduces to the same thing if you define "bug" as "failure to meet
requirements". The trick then is to write bug-free requirements.
Regress until dizzy.
Personally, I'm of the opinion that any bug is one bug too many, but
many people seem to think that they'd rather use the software some time
this side of eternity and are therefore quite happy to put up with the
odd bug.
Well, not happy, but tolerant. Good point, though.

--
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.
Feb 10 '07 #170
Ian Collins <ia******@hotmail.comwrote:
Richard Heathfield wrote:
Ian Collins said:
>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.
In other words, you're testing something different from what you're
sending to your end users. Is that wise?
So the code in question is written in the subset of C that is valid C++.
Valid, but slightly different. Do you want to bet on the slightly being
slight enough, or do you want to compile both as the same language and
make sure?

Richard
Feb 12 '07 #171
Richard Bos wrote:
Ian Collins <ia******@hotmail.comwrote:
>>
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.

In other words, you're testing something different from what you're
sending to your end users. Is that wise?
I think I've answered that elsethread, the code is developed and tested
in a host environment and the acceptance tests are run (very often as
they are automated) on both the simulation and target.
>
>>So the code in question is written in the subset of C that is valid C++.

Valid, but slightly different. Do you want to bet on the slightly being
slight enough, or do you want to compile both as the same language and
make sure?
I don't bet, I test!

--
Ian Collins.
Feb 12 '07 #172

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

Similar topics

5
by: disco | last post by:
I am working on this example from a book "C Primer Plus" by Prata 4th edition - p. 672. There is no erata on this problem at the publisher's website. 1) Is it a violation of copyright laws to...
12
by: f.oppedisano | last post by:
Hi, i would like to allocate two structures making only one malloc call. So i do prt=malloc(sizeof(struct1)+sizeof(struct2)); After this operation i make two pointers one to the first struct...
11
by: Rodrigo Dominguez | last post by:
there are sometimes that I use third party libraries, I use some functions that returns char * or structs, etc. sometimes the memory that is returned by those libraries, when I try to free this...
6
by: Fernando Cacciola | last post by:
Help me out here please: While watching Brad Abraham's MSDN TV talk about the Dispose pattern, refering to: public virtual void Dispose ( bool disposing ) { if ( disposing ) { <-- WHAT...
4
by: Atul Sureka | last post by:
Hi, I want to free the object memory in C# - like we do using 'delete' keyword in C++. Lets say I have an object of some class and I want to explicitly free the memory. C# do not have any free...
66
by: karthikbalaguru | last post by:
Hi, Will 'free' return the memory Immediately to the OS ? Thx in advans, Karthik Balaguru
9
by: david | last post by:
I will past only two segments from the code it should be enough to see what I did wrong, I think I know there I made a mistake, but how to fix it I can not tell. This why I need help from you all....
11
by: vivek | last post by:
Hello, I have a pointer to a main structure which again consists of structures, enums, char, int, float and again complex structures. When i free all the contents of the main structure, it...
25
by: Andreas Eibach | last post by:
Hi again, one of the other big woes I'm having... typedef struct perBlockStru /* (structure) Long words per block */ { unsigned long *lword; } lwperBlockStru_t;
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
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...

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.