compiler behaviour, exported symbols, linking

[chnorik]

I wonder whether it is a standard behaviour for any c compiler:

noch@localhost:~$ cat test2.c
#include <stdio.h>

int miban(){
printf ("aaa\n");
}
noch@localhost:~$ cat test.c

int main(){

miban();

return 0;

}

noch@localhost:~$ cc -c test2.c
noch@localhost:~$ cc -c test.c
noch@localhost:~$ cc -o test test.o test2.o
noch@localhost:~$ ./test
aaa

What I mean, is that I didn't use header file in order to export
miban() from second module.
But... in assembly it is possible to mark symbol to be visible from
outside. I mean, object files support incapsulation concept.

What I see in generated assembly from second module is that miban()
function is marked as .globl
..globl miban
.type miban, @function

This means, that in principle, anyone without inreface specs will be
able to use private functions.

And I want to use this possibility in my codegenerator, because I do
not want to generate header files, they are not necessary for that
custom task

What I want to know is how portable this solution is, i. e. will it
work with _any_ c compiler out there?

 

[jameskuyper]

I wonder whether it is a standard behaviour for any c compiler:

noch@localhost:~$ cat test2.c
#include <stdio.h>

int miban(){
printf ("aaa\n");
}
noch@localhost:~$ cat test.c

int main(){

miban();

return 0;

}

noch@localhost:~$ cc -c test2.c
noch@localhost:~$ cc -c test.c
noch@localhost:~$ cc -o test test.o test2.o
noch@localhost:~$ ./test
aaa

What I mean, is that I didn't use header file in order to export
miban() from second module.

If you're using a compiler in C90 mode, this is perfectly legal, but a
very bad idea. It's so bad, that in C99 it was changed to be a
constraint violation. I'd recommend NOT doing it.

In C90, it works because, in the absence of an explicit declaration,
miban() was implicitly declared as a function returning an 'int' and
taking an unspecified number of arguments. Because this implicit
declaration was consistent with the actual definition of miban, your
program works. Implicit 'int' was dropped in C99.

 

[Fred]

I wonder whether it is a standard behaviour for any c compiler:

noch@localhost:~$ cat test2.c
#include <stdio.h>

int miban(){
printf ("aaa\n");}

noch@localhost:~$ cat test.c

int main(){

miban();

return 0;

}

noch@localhost:~$ cc -c test2.c
noch@localhost:~$ cc -c test.c
noch@localhost:~$ cc -o test test.o test2.o
noch@localhost:~$ ./test
aaa

What I mean, is that I didn't use header file in order to export
miban() from second module.
But... in assembly it is possible to mark symbol to be visible from
outside. I mean, object files support incapsulation concept.

What I see in generated assembly from second module is that miban()
function is marked as .globl
.globl miban
        .type   miban, @function

This means, that in principle, anyone without inreface specs will be
able to use private functions.

You don't have any "private" functions - you decalred them
to be public. If you want them to be priovate,
mark them as static:

In test2.c, use
static int miban(){
printf ("aaa\n");
}

Then see what happens when you try to link.

 

[chnorik]

If you're using a compiler in C90 mode, this is perfectly legal, but a
very bad idea. It's so bad, that in C99 it was changed to be a
constraint violation. I'd recommend NOT doing it.

In C90, it works because, in the absence of an explicit declaration,
miban() was implicitly declared as a function returning an 'int' and
taking an unspecified number of arguments. Because this implicit
declaration was consistent with the actual definition of miban, your
program works. Implicit 'int' was dropped in C99.

actually, I successfully compiled modules with gcc and -std=c99 flag
with only implicit declaration warning

 

[Keith Thompson]

(e-mail address removed) wrote: [...]

What I mean, is that I didn't use header file in order to export
miban() from second module.

If you're using a compiler in C90 mode, this is perfectly legal, but a
very bad idea. It's so bad, that in C99 it was changed to be a
constraint violation. I'd recommend NOT doing it.

In C90, it works because, in the absence of an explicit declaration,
miban() was implicitly declared as a function returning an 'int' and
taking an unspecified number of arguments. Because this implicit
declaration was consistent with the actual definition of miban, your
program works. Implicit 'int' was dropped in C99.

actually, I successfully compiled modules with gcc and -std=c99 flag
with only implicit declaration warning

Not surprising. C doesn't require invalid translation units to be
rejected (the single exception is the #error directive); it merely
requires a diagnostic message for any translation unit containing a
syntax error or constraint violation. A different C99 compiler (and
note that gcc doesn't *fully* implement C99) could easily reject your
code. Ignoring warnings is usually a bad idea.

Why not just write the header file?

 

[James Kuyper]

actually, I successfully compiled modules with gcc and -std=c99 flag
with only implicit declaration warning

An implicit declaration warning is all that the C standard requires it
to provide. The C standard also allows it to reject that program. It's
the second fact that you should pay attention to, at least if
portability is of any concern to you.