Thread: Didn't use to need extern, now I do, don't know what changed? Can anyone help?

It was 'fine' when all you had was a single .h file included in a single .c file.

But the moment you have more than one .c file, you need to fix your approach (as you figured out).

Generally, global data is a poor approach if there are other ways to solve the problem.

Code:

// main.c
#include <stdio.h>
#include "ext1.h"
#define ASIZE 1
int main()
{
 int array[ASIZE];
 mult_me(array,ASIZE,6);
 printf("value of c is: %d",array[0]);
}

// ext1.h
#ifndef EXT1_H_INCLUDED
#define EXT1_H_INCLUDED
int mult_me(int *array, int size, int x);
#endif

// ext1.c
#include "ext1.h"
int mult_me(int *array, int size, int x)
{
    // 
    array[0] = 7*x;
}

By passing the array you want to change as a parameter (it's also good practice to always pass the size of any array), your function no longer cares what name you gave the array.

Your header files should have include guards.
See https://www.geeksforgeeks.org/include-guards-in-c/ for an explanation.

i dunno, what was your code 2 months ago?

Try putting the verbose/debug on your cmake command line, to see what's it's doing.

Just compiling directly using GCC works.

Code:

==> ext1.c <==
#include "ext1.h"
  
int mult_me(int x)
{
    c[0] = 7*x;    
}

==> ext1.h <==
//global array
int c[1];
  
int mult_me(int x);

==> main.c <==
#include <stdio.h>
#include "ext1.h"
  
int main()
{
 mult_me(6);
 printf("value of c is: %d",c[0]);
}

$ gcc -Wall -Wextra main.c ext1.c
ext1.c: In function ‘mult_me’:
ext1.c:7:1: warning: control reaches end of non-void function [-Wreturn-type]
    7 | }
      | ^

$ ./a.out 
value of c is: 42$

Sure, there's a warning, but nothing catastrophic like multiply declared symbols.

> This is a extremely simplified version of the library but the same general idea.
You need to post an extremely simplified version that actually represents the problem, along with your actual error messages and whatever cmake file you used.

Otherwise, it's just hand-waving and "works for me".

Originally Posted by audiodiwhy

Thank you for your reply.



For brevity I didn't include guards here, but they are in my library. I am aware that that is a best practice. Their absence does not impact my overarching question however.



Of course, but respectfully, that's not my question.

Why does code that used to compile, 2 or so months ago, and still compiles without error on online GDB's website, no longer compile?

Does CMAKE, GCC (not sure which one but it was probably one of those) move the goal posts frequently in the world of C?

I apologize if this is a newbie question, but I thought, perhaps incorrectly, that a big draw of C is that it almost never changes--what used to compile for processor X 10-20 years ago will probably still do so today, and something simple that compiles on the onlineGDB site (like the code below) will probably also compile on an Ubuntu linux host using CMAKE and GCC (it won't)

Am I being naive?

Perhaps there is some sort of filter in the CMAKE/GCC world I need to better understand, one that allows or disallows dicey programming practices?

When multiple files include the same header they also define the same things, when it's just the name it's fine as the linker is then responsible for collecting the name definitions and linking them to the contents defined in the files that included those headers. When you define the contents in headers, barring certain exceptions designed specifically for headers like inline functions, you're also defining those same contents multiple times, as a result the files can and will see different addresses for the same name which puts everything out of sync, decidedly the opposite of what you intended, that is the reason defining the contents of a name is generally forbidden in headers. The compiler (gcc in this case) won't be able to catch that area because for all it knows, those headers were specifically designed to be included by just one file (bad practice but still legitimate), the linker on the other hand can catch those areas with the information kept within the object files created by the compiler, object files that were created from the source files that included the headers that defined the contents of the symbol you meant to have synced between files, so in reality, assuming you used multiple files when it worked then the version of the linker &/or compiler you used at the time was not properly made, in other words it was a bug that caused your original code to work, not a standard feature.