Very strange bug in C, please help

V

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[j], and the second for k. 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, the values of v[j]s change
and are set to be equal some values of k. 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[j]=4;

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

k=10;
}





return(0);
}

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

exit(1);
}
 
M

Martin Ambuhl

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[j], and the second for k. 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, the values of v[j]s change
and are set to be equal some values of k. 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 said:
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[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=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.
 
V

VijaKhara

WOW thank you guys very much.



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[j], and the second for k. 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, the values of v[j]s change
and are set to be equal some values of k. 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 said:
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[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=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 -
 
J

jaysome

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[j], and the second for k. 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, the values of v[j]s change
and are set to be equal some values of k. 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.h> and 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
 
R

Richard Heathfield

jaysome said:
(e-mail address removed) wrote:
#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".
Can you elaborate on why it "probably shouldn't"?

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

That's why it probably shouldn't.
 
C

CBFalconer

jaysome said:
Martin Ambuhl said:
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[j], and the second for k. 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, the values of v[j]s
change and are set to be equal some values of k. 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.h> and 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
 
M

Mark L Pappin

Because that might happen. UB is wonderful stuff.
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.h> and the User who wrote
"time.h" (which became "efsl_time.h") used something from _his_
namespace (and therefore non-conflicting by definition) there.

mlp
 
S

Stephen Sprunk

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

I've run into trouble using EFSL when someone else included both
<time.h> and 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
 
C

CBFalconer

Mark said:
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.h> and 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
 
M

Mark L Pappin

CBFalconer said:
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.h> because <time.h> may
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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top