Very strange bug in C, please help

[VijaKhara]

Hi all,
I just write a very simple codes in C and vthere is a very strange bug
which I cannot figure out why.

The first loop is for v[i][j], and the second for k[i]. There is no
relationship between v and k but if I debug and watch the change of
the variable after each command.

When the sencond loop happends for k[i], the values of v[i][j]s change
and are set to be equal some values of k[i]. Specifically, v[1][1] is
set to be 10, so is v[1][2] .
I don't understand why. It seems that both v and k point to the same
address in memory.
This is very strange.

(I write this C code in Visual Studio 6 and debug it in Visual Studio
6)

Thanks
#include <math.h>
#include <stdlib.h>
#include "time.h"

void error(char *name);

int main (int argc, char **argv)
{
double v[3][3];
double k[3];
int i,j,l;


for (i=0;i<3;i++)
for(j=0;j<3;j++)
v[i][j]=4;

for (i=0;i<9;i++)
{

k[i]=10;
}

return(0);
}

void error(char *name)
{
printf("usage: %s image.tiff \n\n",name);

exit(1);
}

[Richard Heathfield]

Vi*******@gmail.com said:

<snip>

double k[3];

<snip>

for (i=0;i<9;i++)
{

k[i]=10;
}

k has only three elements, and you are writing to all nine of them.
That's not good.

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

[Martin Ambuhl]

Vi*******@gmail.com wrote:

Hi all,
I just write a very simple codes in C and vthere is a very strange bug
which I cannot figure out why.

The first loop is for v[i][j], and the second for k[i]. There is no
relationship between v and k but if I debug and watch the change of
the variable after each command.

When the sencond loop happends for k[i], the values of v[i][j]s change
and are set to be equal some values of k[i]. Specifically, v[1][1] is
set to be 10, so is v[1][2] .
I don't understand why. It seems that both v and k point to the same
address in memory.
This is very strange.

(I write this C code in Visual Studio 6 and debug it in Visual Studio
6)

Thanks
#include <math.h>
#include <stdlib.h>
#include "time.h"

If you have your own private "time.h", you probably shouldn't. The
standard header is <time.h>. You don't use either here, of course.

void error(char *name);

int main (int argc, char **argv)
{
double v[3][3];
double k[3];
int i,j,l;
for (i=0;i<3;i++)
for(j=0;j<3;j++)
v[i][j]=4;

for (i=0;i<9;i++)

^^^^
As soon as you access k[3] you are in never-never land. There are no
such objects as k[3] through k[8] and you don't own the memory where
they might be.

{
k[i]=10;
}
return 0;
}

void error(char *name)
{
printf("usage: %s image.tiff \n\n",name);
exit(1);

^^^^^^
Use one of the defined values for arguments to exit, namely, 0,
EXIT_SUCCESS, and EXIT_FAILURE. 1 has no standard meaning as an
argument for exit.

}

[VijaKhara]

WOW thank you guys very much.

On Apr 10, 5:22 pm, Martin Ambuhl <[e-mail]:

[e-mail] wrote:

Hi all,
I just write a very simple codes in C and vthere is a very strange bug
which I cannot figure out why.

The first loop is for v[i][j], and the second for k[i]. There is no
relationship between v and k but if I debug and watch the change of
the variable after each command.

When the sencond loop happends for k[i], the values of v[i][j]s change
and are set to be equal some values of k[i]. Specifically, v[1][1] is
set to be 10, so is v[1][2] .
I don't understand why. It seems that both v and k point to the same
address in memory.
This is very strange.

(I write this C code in Visual Studio 6 and debug it in Visual Studio
6)

Thanks

#include <math.h>
#include <stdlib.h>
#include "time.h"

If you have your own private "time.h", you probably shouldn't. The
standard header is <time.h>. You don't use either here, of course.

void error(char *name);

int main (int argc, char **argv)
{
double v[3][3];
double k[3];
int i,j,l;
for (i=0;i<3;i++)
for(j=0;j<3;j++)
v[i][j]=4;
for (i=0;i<9;i++)

^^^^
As soon as you access k[3] you are in never-never land. There are no
such objects as k[3] through k[8] and you don't own the memory where
they might be.

{
k[i]=10;
}
return 0;
}

void error(char *name)
{
printf("usage: %s image.tiff \n\n",name);
exit(1);

^^^^^^
Use one of the defined values for arguments to exit, namely, 0,
EXIT_SUCCESS, and EXIT_FAILURE. 1 has no standard meaning as an
argument for exit.

}- Hide quoted text -

- Show quoted text -- Hide quoted text -

- Show quoted text -

[Default User]

Vi*******@gmail.com wrote:

WOW thank you guys very much.

Please don't top-post. Your replies belong following or interspersed
with properly trimmed quotes. See the majority of other posts in the
newsgroup, or:
<http://www.caliburn.nl/topposting.html>

[jaysome]

On Tue, 10 Apr 2007 17:22:18 -0400, Martin Ambuhl
<ma*****@earthlink.netwrote:

>Vi*******@gmail.com wrote:

>Hi all,
I just write a very simple codes in C and vthere is a very strange bug
which I cannot figure out why.

The first loop is for v[i][j], and the second for k[i]. There is no
relationship between v and k but if I debug and watch the change of
the variable after each command.

When the sencond loop happends for k[i], the values of v[i][j]s change
and are set to be equal some values of k[i]. Specifically, v[1][1] is
set to be 10, so is v[1][2] .
I don't understand why. It seems that both v and k point to the same
address in memory.
This is very strange.

(I write this C code in Visual Studio 6 and debug it in Visual Studio
6)

Thanks
#include <math.h>
#include <stdlib.h>
#include "time.h"

If you have your own private "time.h", you probably shouldn't. The
standard header is <time.h>. You don't use either here, of course.

The Embedded File Systems Library (EFSL) has its own private "time.h".

http://www.efsl.be/
http://sourceforge.net/projects/efsl/

Can you elaborate on why it "probably shouldn't"?

I've run into trouble using EFSL when someone else included both
<time.hand some EFSL headers that included "time.h" and the compiler
gave errors.

I'd never have my own private "time.h" and in fact I renamed the EFSL
"time.h" to "efsl_time.h" to fix the above-mentioned compiler errors.

Thanks
--
jay

[Richard Heathfield]

jaysome said:

On Tue, 10 Apr 2007 17:22:18 -0400, Martin Ambuhl wrote:

>>Vi*******@gmail.com wrote:

<snip>

>>#include "time.h"

If you have your own private "time.h", you probably shouldn't. [...]

The Embedded File Systems Library (EFSL) has its own private "time.h".

<snip>

Can you elaborate on why it "probably shouldn't"?

I've run into trouble using EFSL when someone else included both
<time.hand some EFSL headers that included "time.h" and the compiler
gave errors.

That's why it probably shouldn't.

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

[CBFalconer]

jaysome wrote:

Martin Ambuhl <ma*****@earthlink.netwrote:

>Vi*******@gmail.com wrote:

>>>
I just write a very simple codes in C and vthere is a very
strange bug which I cannot figure out why.

The first loop is for v[i][j], and the second for k[i]. There
is no relationship between v and k but if I debug and watch the
change of the variable after each command.

When the sencond loop happends for k[i], the values of v[i][j]s
change and are set to be equal some values of k[i]. Specifically,
v[1][1] is set to be 10, so is v[1][2]. I don't understand why.
It seems that both v and k point to the same address in memory.
This is very strange.

(I write this C code in Visual Studio 6 and debug it in Visual
Studio 6)

#include <math.h>
#include <stdlib.h>
#include "time.h"

If you have your own private "time.h", you probably shouldn't.
The standard header is <time.h>. You don't use either here, of
course.

The Embedded File Systems Library (EFSL) has its own private
"time.h".

http://www.efsl.be/
http://sourceforge.net/projects/efsl/

Can you elaborate on why it "probably shouldn't"?

I've run into trouble using EFSL when someone else included both
<time.hand some EFSL headers that included "time.h" and the
compiler gave errors.

I'd never have my own private "time.h" and in fact I renamed the
EFSL "time.h" to "efsl_time.h" to fix the above-mentioned
compiler errors.

You should check both .h files for such things as equal double
include prevention markers.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews
--
Posted via a free Usenet account from http://www.teranews.com

[Mark L Pappin]

CBFalconer <cb********@yahoo.comwrites:

jaysome wrote:

>Martin Ambuhl <ma*****@earthlink.netwrote:

>>Vi*******@gmail.com wrote:
#include "time.h"

If you have your own private "time.h", you probably shouldn't.

....

>Can you elaborate on why it "probably shouldn't"?

My guess as to Martin's reasoning: because <time.hexists;
or to put it another way:

>I've run into trouble using EFSL when someone else included both
<time.hand some EFSL headers that included "time.h" and the
compiler gave errors.

Because that might happen. UB is wonderful stuff.

>I'd never have my own private "time.h" and in fact I renamed the
EFSL "time.h" to "efsl_time.h" to fix the above-mentioned
compiler errors.

You should check both .h files for such things as equal double
include prevention markers.

In Theory (wonderful place, but after visiting you often don't want to
go home) this Could Not Possibly be a problem because the Implementor
used something from his namespace in <time.hand the User who wrote
"time.h" (which became "efsl_time.h") used something from _his_
namespace (and therefore non-conflicting by definition) there.

mlp

[Stephen Sprunk]

"jaysome" <ja*****@hotmail.comwrote in message
news:or********************************@4ax.com...

Can you elaborate on why it "probably shouldn't"?

I've run into trouble using EFSL when someone else included both
<time.hand some EFSL headers that included "time.h" and the
compiler gave errors.

Be glad you got an error. Some compilers may consider "time.h" and <time.h>
to mean the same thing, or close enough to the same thing that it'll break
your code. More importantly, humans reading your code are almost certain to
make the same mistake, leading to maintenance headaches.

S

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov
--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

Mark L Pappin wrote:

CBFalconer <cb********@yahoo.comwrites:

>jaysome wrote:

.... snip ...

>>

>>I'd never have my own private "time.h" and in fact I renamed the
EFSL "time.h" to "efsl_time.h" to fix the above-mentioned
compiler errors.

You should check both .h files for such things as equal double
include prevention markers.

In Theory (wonderful place, but after visiting you often don't want to
go home) this Could Not Possibly be a problem because the Implementor
used something from his namespace in <time.hand the User who wrote
"time.h" (which became "efsl_time.h") used something from _his_
namespace (and therefore non-conflicting by definition) there.

He said he "renamed" the EFSL "time.h". It might have an internal
variable of the form "H_time_h" (or whatever) that has not been
altered, and which conflicts with <time.h>.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

--
Posted via a free Usenet account from http://www.teranews.com

[Mark L Pappin]

CBFalconer <cb********@yahoo.comwrites:

Mark L Pappin wrote:

>CBFalconer <cb********@yahoo.comwrites:

>>jaysome wrote:
I'd never have my own private "time.h" and in fact I renamed the
EFSL "time.h" to "efsl_time.h" to fix the above-mentioned
compiler errors.

You should check both .h files for such things as equal double
include prevention markers.

In Theory (wonderful place, but after visiting you often don't want to
go home) this Could Not Possibly be a problem because the Implementor
used something from his namespace in <time.hand the User who wrote
"time.h" (which became "efsl_time.h") used something from _his_
namespace (and therefore non-conflicting by definition) there.

He said he "renamed" the EFSL "time.h". It might have an internal
variable of the form "H_time_h" (or whatever) that has not been
altered, and which conflicts with <time.h>.

The EFSL "time.h" now called "efsl_time.h", which is not part of the C
implementation, might have such an identifier but this Could Not
Possibly conflict with anything in <time.hbecause <time.hmay
contain only that which the standard says it may contain, and things
in the User's namespace are not in that list. If your <time.h>
contains such things, complain to your compiler vendor.

You know this stuff, Chuck. Furrfu.

mlp