0

I'm having a very strange problem with variables changing their value incorrectly inside my C code. I'm using GCC inside Qt Creator for this project.

I have a common C project with a main.c file and, among other files, two pairs of .c and .h (battery_general.c/.h and fpga_gps.c/.h). Both the battery and GPS systems required a "timeout" method to be periodically called inside a timer event (I'm actually using a while(1) with sleep(1) for this). In both the timeout functions of battery and GPS, I have a uint16_t timer called timeoutCounter which is incremented when the timeout() functions are called till 120, when their value is reset to 0. This "timeoutCounter" integers are declared inside the global scope of each respective .c file, and they don't have any access to each other content. Only in main.c is that both .h are included so I may call the timeout() functions.

In the call logic inside the while loop, the battery timeout() is called before the GPS one and it happens that the battery's timeoutCounter is put to 0 before the call to the GPS' timeout() function.

What is happening is that, when the call to the GPS' timeout occurs, its timeoutCounter (which was started with a value of 121) is set to 0 when it's first used - a place when it should be 121 since no modification to its value has being done yet. It's as if the assigning to 0 of the battery's timeoutCounter was affecting the timeoutCounter inside the GPS's .c file even if they have no connection to each other! For when I change the timeoutCounter inside the GPS's .c file (to gpsTimeoutCounter, for example), the bug dissapears!

Could it be the case the GCC is mistakenly thinking that both variables are the same eventhough I didn't use extern and the files are not related (no #include between them) just because they are of the same type and have the same name? It sure looks like a bug in GCC!

Anyway, what could be happening? If code is needed, I'l post some, but everything relevant was described. I did lots of tests (global search, debug, etc.) to verify if there was some kind of connection mistakenly being made between the two .c files and nothing was found. And it is as I sad: I just change the name of one of the variables and the bug disappears, and if I change both variables to a different, same name (e.g. both are called gpsTimeoutCounter), the bug appears again!

Momergil
  • 2,213
  • 5
  • 29
  • 59
  • 1
    possible duplicate of [C the same global variable defined in different files](http://stackoverflow.com/questions/17800187/c-the-same-global-variable-defined-in-different-files) – ericbn Sep 24 '14 at 20:19
  • Did you use a debugger (so compile with `gcc -Wall -g`, then use `gdb`). You should use watchpoints in `gdb` – Basile Starynkevitch Sep 24 '14 at 20:25
  • @ericbn although I would say my question is not a duplicate, it seems that the link you provided do talk about the same problem - and it was useful for me to comprehend the situation. Thanks! – Momergil Sep 24 '14 at 20:32

1 Answers1

2

Yes, gcc can treat global variables in distinct files as the same symbol if they have the same name. This happens in the linking stage, when you have two object .o files generated from different source .c files, and both declare a "external" (global) definition with the same name.

I happens even if you don't use extern in your header .h files. This is just to tell the compiler and linker that the extern (it means "external linkage") definition was declared elsewhere (so there is no need to allocate more space for that definition, it has already been declared).

ericbn
  • 10,163
  • 3
  • 47
  • 55
  • so, what you're essentially saying is that if I declare two global variables with the same name, even if its inside two different and specific .c (which is not main.c) and has no `extern` associated with any of them, C will still treat as if I'm talking about the same variable? As if I'm declaring the same variable twice? But if it understands that I'm declaring the same variable twice, then why no warning is shown? – Momergil Sep 24 '14 at 20:28
  • Yes, that's what I'm saying. It depends on the linker, but it should give you a warnings like `multiple definition of ...` and `first defined here`. – ericbn Sep 24 '14 at 20:31
  • well, that definitively helped me negatively, for the linker doesn't provide any warning when I have this two variables with the same identifier =T If the warning was given, I'ld probably figured it out soon. Thanks for the answer! – Momergil Sep 24 '14 at 20:34