compiler behaviour, exported symbols, linking

C

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?
 
J

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.
 
F

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.
 
C

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
 
K

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?
 
J

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.
 

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