Confused about -Wimplicit-function-declaration

[barryk]

I downloaded bacon 3.4 yesterday and compiled it for x86_64.

A couple of my utility applications compile ok, but with an error message. For example:

Compiling 'pup_event_frontend_d.bac'... cc  -c pup_event_frontend_d.bac.c
cc -o pup_event_frontend_d pup_event_frontend_d.bac.o -lbacon -lm
Compiler error:

Description:
file 'pup_event_frontend_d.bac' line 78: eventstatus=poll(&pfd.fd, 1, 1000)
Cause:
implicit declaration of function 'poll' [-Wimplicit-function-declaration]

I never used to get that error message. i think that the last time I compiled that particular utility was with bacon 3.3 and did not get that error.

Inside pup_event_frontend_d.bac, I have this:

PROTO getpid, socket, bind, poll, recv, printf, strlen, strcmp

then further down:

eventstatus=poll(&pfd.fd, 1, 1000)

However, if I just compile directly like this:

# cc -Wimplicit-function-declaration -o pup_event_frontend_d pup_event_frontend_d.bac.o -lbacon -lm
#

...there is no error message.

I have attached the entire file.

Attachments:

pup_event_frontend_d.bac.gz (2.18 KB)

[barryk]

Ah, I get that error at the previous step:

# cc -Wimplicit-function-declaration  -c pup_event_frontend_d.bac.c
pup_event_frontend_d.bac.c: In function ‘main’:
pup_event_frontend_d.bac.c:160:18: warning: implicit declaration of function ‘poll’ [-Wimplicit-function-declaration]
eventstatus=(int)poll(&pfd.fd, 1, 1000);

The utility compiles. Should I be concerned about this message?
Why didn't I get it with earlier bacons?

The poll() function is described here:

linux.die.net/man/2/poll

I am wondering if my memory is faulty and I did get that error message back with 3.3.
Again, my memory could be faulty, but I don't think I got the message back when I originally compiled this utility, a few years ago.

[Pjot]

Hi barryk,

Thanks for your report. Management summary: the error message is harmless, and the resulting binary should work fine. The 'poll' function is part of 'libc', and the resulting binary always links with libc.so. Therefore, the program will work.

I can reproduce the issue, but for me, it also fails with BaCon 3.3. As a matter of fact, your code always produces the compile warning for BaCon versions 3.x and higher.

So, why does the PROTO statement not help you here? The PROTO statement is meant for the BaCon parser, so it does not choke on unknown statements during conversion time. But in your code, you use 'poll' as a function. It is part of an assignment, which, behind the scenes, is taken as a LET.

So this:

eventstatus = poll(&pfd.fd, 1, 1000)


...actually means...

LET eventstatus = poll(&pfd.fd, 1, 1000)


The LET keyword is known to BaCon, and therefore, it will accept your construct during conversion time. So, PROTO only relates to code which appears as a statement, and which therefore has to be accepted by the BaCon parser during conversion time.

However, the error you are facing does not happen during conversion time. It reveals itself during compile time. The error clearly explains the problem: there is a function which cannot be recognized during compile time.

In order for the C compiler to recognize the 'poll' function, we need to add an include file.

PRAGMA INCLUDE <poll.h>


And of course, we can remove the 'poll' from the list in PROTO as well, because it does not make sense to define it there (though it does not hurt either).

Anyway, in spite of this missing header file, the resulting binary will work, because BaCon always will link to 'libc.so'. The 'poll' function can be looked up in this library, and therefore, the linking succeeds.

It is all quite confusing, but I hope my explanation makes any sense.

Best regards
Peter

[barryk]

Thanks very much for the explanation!

Yes, the main point of confusion was because poll() was defined in PROTO, so I didn't see why there should be an "error" message.

Anyway, good to know that my utility still works, I'll leave the code as it is.