Trouble with pointers

[Michael]

Hi in here,

I have a problem with the following lines of code:

printf("\tCalc this:\t %f * (%f -%f) = %f\n",
tCtrl->dGain, *p_dDesiredValues, *p_dActualValues,
( tCtrl->dGain * (*p_dDesiredValues-*p_dActualValues )));

They are part of a function, where
tCtrl is a pointer to a struct
containing a double called
'dGain'
p_dDesiredValues Pointer to double
p_dActualValues Pointer to another double.

Sometimes the command gives the weird output:
Calc this: 6.000000 * (2.000000 -1.800000) = -1.#IND00

If I put the same statement twice, the second always gives:
Calc this: 6.000000 * (2.000000 -1.800000) = 1.200000

Well, the real thing is that this is not part of an
C-program, but an subroutine to an numerical math tool.
The subroutine is written in c.
I know this is off topic here. That's why I just want to
know if something of the above thing is wrong in 'c-sense',
or if it's ok and the error must be somewhere else.

Regards,
Michael

[Al Bowers]

Michael wrote:

Hi in here,

I have a problem with the following lines of code:

printf("\tCalc this:\t %f * (%f -%f) = %f\n",
tCtrl->dGain, *p_dDesiredValues, *p_dActualValues,
( tCtrl->dGain * (*p_dDesiredValues-*p_dActualValues )));

They are part of a function, where
tCtrl is a pointer to a struct
containing a double called
'dGain'
p_dDesiredValues Pointer to double
p_dActualValues Pointer to another double.

Sometimes the command gives the weird output:
Calc this: 6.000000 * (2.000000 -1.800000) = -1.#IND00

If I put the same statement twice, the second always gives:
Calc this: 6.000000 * (2.000000 -1.800000) = 1.200000

Well, the real thing is that this is not part of an
C-program, but an subroutine to an numerical math tool.
The subroutine is written in c.
I know this is off topic here. That's why I just want to
know if something of the above thing is wrong in 'c-sense',
or if it's ok and the error must be somewhere else.

If the variables are as you describe, I do not see anything
wrong with the printf statement. I applied the printf
statement in the following code and got the output:

Calc this: 8.000000 * (2.000000 -1.800000) = 1.600000

The Code:

#include <stdio.h>

struct TEST
{
double dGain;
};

int main(void)
{
double arr[] = {2.0,1.8};
struct TEST test = {8.0};
struct TEST *tCtrl = &test;
double *p_dDesiredValues = &arr[0];
double *p_dActualValues = &arr[1];

printf("\tCalc this:\t %f * (%f -%f) = %f\n",
tCtrl->dGain, *p_dDesiredValues, *p_dActualValues,
( tCtrl->dGain * (*p_dDesiredValues-*p_dActualValues )));
return 0;
}
--
Al Bowers
Tampa, Fl USA
mailto: xa******@myrapidsys.com (remove the x to send email)
http://www.geocities.com/abowers822/

[Michael]

Hi thanks,

hmm, so there are no side effects. What really
scares me is the fact that the parameters are
printed correct, but their combination isn't.

Thanks again.

What does the wrong output "-1.#IND00" mean?
Is this already crap from the program on top,
or created by printf in case wrong values in variables?

Regards
Michael

Al Bowers schrieb:

If the variables are as you describe, I do not see anything
wrong with the printf statement. I applied the printf
statement in the following code and got the output:

Calc this: 8.000000 * (2.000000 -1.800000) = 1.600000

The Code:

[...]

[Mark McIntyre]

On Tue, 11 May 2004 17:50:32 +0200, in comp.lang.c , Michael
<mi****@gmx.net> wrote:

Hi thanks,

hmm, so there are no side effects. What really
scares me is the fact that the parameters are
printed correct, but their combination isn't.

Thanks again.

What does the wrong output "-1.#IND00" mean?

Given that your code is valid, it means that your stack was scrambled
before you even got into that part of the code.

You're debugging the wrong place. Somewhere else in your programme, you
wandered off an array bound, used an uninitialised variable, or otherwise
Broke the Rules. This resulted in your programme going subtly wrong, but
the problem did not manifest itself till the line you are examining.

You need to examine the code earlier in the execution cycle.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[Michael]

Hi Mark,

that was a good hint, thanks a lot. I missed
to include math.h at the right place so I guess,
after calling 'floor' I got a mess somewhere.
But wonder why my compiler doesn't notify that
there is no floor-function. Maybe that's because
it is part of the 'num-math'-programm

Bye,
Michael

Mark McIntyre wrote:

Given that your code is valid, it means that your stack was scrambled
before you even got into that part of the code.

You're debugging the wrong place. Somewhere else in your programme, you
wandered off an array bound, used an uninitialised variable, or otherwise
Broke the Rules. This resulted in your programme going subtly wrong, but
the problem did not manifest itself till the line you are examining.

You need to examine the code earlier in the execution cycle.

[Dan Pop]

In <c7*********@rzcomm2.rz.tu-bs.de> Michael <mi****@gmx.net> writes:

that was a good hint, thanks a lot. I missed
to include math.h at the right place so I guess,
after calling 'floor' I got a mess somewhere.
But wonder why my compiler doesn't notify that
there is no floor-function.

For the simple reason that there *is* a floor function, whether you
include <math.h> or not. The purpose of including <math.h> is not
providing the function, it is providing *correct* information about the
function, so that the compiler knows how to *correctly* call it. In the
absence of this information, the compiler *must* assume that the function
returns an int value, which is wrong in the case of floor.

Most compilers have an option that triggers warnings about functions that
are called without being previously declared. You *really* want to use
it.

The good news is that C99 enforces such declarations. The bad news is
that old style declarations are enough to make C99 happy.

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

[Michael]

Hi Dan,

thanks for reply. I was used to get warnings
in those cases, so I thought there will always be
one. Always nice to get new knowledge about c, helping
me to avoid such errors in future. I'll check the flags
more carefully then.
But why isn't there a problem when linking the stuff?
I would expect at least a warning, because there is no
'int floor(.)' arround?

Thanks,
Michael

Dan Pop wrote:

For the simple reason that there *is* a floor function, whether you
include <math.h> or not. The purpose of including <math.h> is not
providing the function, it is providing *correct* information about the
function, so that the compiler knows how to *correctly* call it. In the
absence of this information, the compiler *must* assume that the function
returns an int value, which is wrong in the case of floor.
[...]

[Dan Pop]

In <c7**********@rzcomm2.rz.tu-bs.de> Michael <mi****@gmx.net> writes:

But why isn't there a problem when linking the stuff?
I would expect at least a warning, because there is no
'int floor(.)' arround?

The typical linker is very dumb. It merely looks for a symbol named
"floor" in the libraries, without paying any attention to how it was
declared in the C program. Once it finds it, it is happy. Proof:

fangorn:~/tmp 10> cat test.c
#include <stdio.h>
extern int floor;

int main()
{
printf("%d\n", floor);
return 0;
}
fangorn:~/tmp 11> gcc -Wall test.c -lm
fangorn:~/tmp 12> ./a.out
-1783093761
fangorn:~/tmp 13> gcc -Wall test.c
/tmp/ccggvCnb.o(.text+0x11): In function `main':
: undefined reference to `floor'

This example clearly shows that the floor function from libm.a was good
enough for the floor identifier declared by my program, as far as the
linker was concerned, despite the complete incompatibility of type.

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

[Mark McIntyre]

On Wed, 12 May 2004 17:35:10 +0200, in comp.lang.c , Michael
<mi****@gmx.net> wrote:

Hi Dan,

thanks for reply. I was used to get warnings
in those cases, so I thought there will always be
one. Always nice to get new knowledge about c, helping
me to avoid such errors in future. I'll check the flags
more carefully then.
Absolutely. Always have warninglevels as high as possible.
But why isn't there a problem when linking the stuff?
I would expect at least a warning, because there is no
'int floor(.)' arround?

at the linker stage, the linker is merely looking for a fn with the right
name, its no longer concerned about arguments or return types.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[Michael]

Hi,
and thanks to both of you.
Slowly I understand the advice of my uncle,
"Think of the compiler working like:
Thats the way you want it, here you are!"
Bye and enjoy the rest of the week

Michael

Mark McIntyre wrote:

at the linker stage, the linker is merely looking for a fn with the right
name, its no longer concerned about arguments or return types.