Executing c command in c

[LiveForIt]

create a file called header.h

include header.h into the two files.

declare all the functions in header.h as extern
in the file header.h write

extern int function();

every file that header.h is included into, the compiler will know that there is a "int function()" somewhere, maybe not in this .cpp or .c file.

and try to not name your function "function", you might stumble onto keywords that compiler misinterprets.

[LiveForIt]

I do have the header files and they are referenced in the c files.
What I haven't done is added the extern function lines in the main h file.
I have done it for variables that are passed between files.

Any function or variable that is not defined in the .cpp has to decaled with "extern", if you don't compiler will think the function is in the .c / .cpp file and fail.

function1()

If you have function like this one that does return a return value, you should declare it with void.

void function1() {
// do stuff
}

main()

should always be declared as "int main()", main should always return a value, or else you can get some strange messages in Shell.

because I have used fp in main.c would I need to set an extern File *fp in one of the headers to use it again in other.c ? Even though fp was declared locally in both function1 and function2 ?
My current way of thinking is that I wouldn't need to because the 2 fps are actually different because they are not declared globally.

You are correct

because I have used fp in main.c would I need to set an extern File *fp in one of the headers to use it again in other.c ?

As long as FILE *fp is declared inside the code block start { and }, its local variable, to that code block. Local variable are declared on the stack, sometime it might idea declare locals inside sub blocks inside function, saves the CPU from initialize variables that is not used.

You might have seen the typical

for (int I=0; I<10; I++) {
}

Counter "I", is only used once and declared only when it's needed.

[LiveForIt]

You need to include the same files in all .c / .cpp files.
and you need to compile the .c/.cpp correct.

normally compile file2, file3 into a object, like

vbcc file2.c -o file2.o -c
vbcc file3.c -o file3.o -c

"-c" tells the compiler to make a object.

the you need to list all your file when compiling the main.c

vbcc main.c file2.o file3.o -o main.exe

some thing like that, I'm used to GCC, on AmigaOS4.1 :-), so you might need to look things up for vbcc.

[LiveForIt]

If wont to copy a string, I normally use

char *strdup(char *)

Because it bundles malloc() and strcpy()

there is also strndup() if you only need a part of a text string, might not be included older C standard lib's.

sprintf is best used for converting or formatting a text.

as for sprintf being unsafe, its only unsafe if don't calculate required buffer size in advanced, and use malloc to create a buffer.
Sure snprintf is safer, but it might be tiny bit slower, because it checks for if at end of buffer.

static buffer like

char mybuffer[33]; might really unsafe, imaging using this for file names, as old FFS files was only 32 chars, it was not a problem, but then newer versions of file systems started to support 128 char names.

It important to know etch function has It's own use, and don't try to make assumptions.

There is also

salloc()

The cool thing about it is that it allocates memory on the stack, so when exit a function, you get memory back with out freeing it, the disadvantage is that stack is predefined on AmigaOS and can't be auto increased, while program is running. so running out stack memory can be real issue.

maybe better to stick to malloc().

There are also AllovVec() and AllocMem() in Exec.library, this most not be mixed with malloc(), and free().

[LiveForIt]

ah, its a macro.