|
|
Post by barryk on Feb 16, 2018 1:51:43 GMT 1
Hi guys. I am mystified. Using BaCon 3.7.1, I have compiled the attached file, but it gives a warning message: Description:
file './pup_event_d.bac' line 72: eventstatus=poll(&pfd.fd, 1, 30000)
Cause:
implicit declaration of function 'poll' [-Wimplicit-function-declaration]The program does declare poll, in a PROTO: PROTO getpid, socket, bind, poll, recv, printf, strlen, strcmpBaCon is happy with all of the other functions, why does it single out poll only? poll() is a glibc function. It is there, the program compiles, and works, just have this warning. How to fix it, so don't get that warning? Attachments:pup_event_d.bac (4.79 KB)
|
|
|
|
Post by barryk on Feb 16, 2018 2:02:53 GMT 1
|
|
|
|
Post by barryk on Feb 16, 2018 2:41:10 GMT 1
I inserted:
PRAGMA INCLUDE <poll.h>
But now I get a conflict:
pup_event_d.bac.c:198:24: warning: passing argument 1 of 'poll' from incompatible pointer type [-Wincompatible-pointer-types]
eventstatus=(int)(poll(&pfd.fd, 1, 30000));
^
In file included from /usr/include/poll.h:1:0,
from pup_event_d.bac.h:23,
from pup_event_d.bac.c:2:
/usr/include/sys/poll.h:56:12: note: expected 'struct pollfd *' but argument is of type 'int *'
poll.h defines:
struct pollfd
{
int fd; /* File descriptor to poll. */
short int events; /* Types of events poller cares about. */
short int revents; /* Types of events that actually occurred. */
};
extern int poll (struct pollfd *__fds, nfds_t __nfds, int __timeout);
I "fixed" it, by changing line 56 in my program:
eventstatus=poll((struct pollfd *)&pfd.fd, 1, 30000)
...not terribly confortable with doing that, but it seems ok.
Looking a C code examples, it is done like this:
struct pollfd fds[1];
...
fds[0].fd = something here;
...
ret = poll(fds, 1, timeout_msecs);
|
|
|
|
Post by barryk on Feb 16, 2018 9:44:20 GMT 1
Rereading what I have posted, the fix looks logical.
I was surprised though, that a C type-cast worked in a BaCon program:
(struct pollfd *)&pfd.fd
I guess that must be because BaCon is said to be a "lazy converter'.
|
|
|
|
Post by vovchik on Feb 16, 2018 12:03:24 GMT 1
Dear Barry, It's great that you posted the problem and - within a very short time - posted the solution.  With kind regards, vovchik |
|
|
|
Post by bigbass on Feb 16, 2018 18:31:43 GMT 1
Hello barryk
I know you are looking for some cut down way to hotplug
and you prefer to keep it as short and to the point as possible
so I kept everything the way you wanted to do it
The problem that caused this
is gcc got stricter and complains a lot more than before
and poll is being "borrowed" but works
if you are happy how your code works and don't want to change it
you could just add -Wno-implicit-function-declaration
using the bacon GUI compiler there is an entry box Options:
to add that line
to get a clean compile
if you want to remove the USEC in two places
P.S a very interesting code snippet thanks for posting it
Thanks again for all your work and the fun I had using it!
Joe
'USEC
' dont forget to add close to PROTO at the top of this code
'/*#define O_WRONLY 00000001*/
'/*#define O_APPEND 00002000*/
DECLARE clientdesc TYPE int
DECLARE wr TYPE int
clientdescr=open(clientfile, O_WRONLY | O_APPEND)
IF (clientdescr>0) THEN
wr=write(clientdescr,outmsg,strlen(outmsg))
close(clientdescr)
ENDIF
'END USEC
'USEC
'/*#define O_WRONLY 00000001*/
'/*#define O_APPEND 00002000*/
'int clientdescr;
clientdescr=open(clientfile, O_WRONLY | O_APPEND)
IF (clientdescr>0) THEN
wr=write(clientdescr,outmsg,strlen(outmsg))
close(clientdescr)
END IF
'END USEC
|
|
|
|
Post by Pjot on Feb 16, 2018 20:11:58 GMT 1
Hi barryk, Next to the suggestion of bigbass, how about using OPEN FOR APPENDING and then use WRITELN to write data to the file? If this is the code: USEC
/*#define O_WRONLY 00000001*/
/*#define O_APPEND 00002000*/
int clientdescr;
clientdescr=open(clientfile, O_WRONLY | O_APPEND);
if (clientdescr>0) {
int wr=write(clientdescr,outmsg,strlen(outmsg));
close(clientdescr);
}
END USEC
...then it easily can be rewritten to: OPEN clientfile FOR APPENDING AS clientdescr
IF clientdescr THEN WRITELN outmsg;
CLOSE clientdesc
Note the semicolon at the WRITELN statement, which prevents writing a newline. You can even shorten these three lines further by a single APPEND statement introduced by vovchik: APPEND outmsg TO clientfile
The APPEND statement opens a file, only writes the data in the stringbuffer 'outmsg' and no additional newlines, then closes it. Regarding the 'poll', which is similar to 'select', it seems this can be replaced by the WAIT function. This way you can use 100% BaCon code without the compile issues. As a bonus, your code is shorter too HTH Peter |
|
|
|
Post by barryk on Feb 17, 2018 12:29:10 GMT 1
Thanks for the feedback, extremely helpful!
pup_event_d.bac is a work-in-progress.
One bug in the code that I posted earlier, is it has opendir(), but without a closedir().
...Puppy Linux has a similar program, named pup_event_frontend_d, which also has this bug.
...I wonder what the repercussion is? If opendir() keeps re-running, without any closedir(), is that going to cause some resources somewhere to get used up?
Anyway, that pup_event stuff in Puppy is very old, last time that I looked at it was 2014, and it was mostly developed in 2012.
Revisiting the topic, and doing a major cleanup.
It is working with the USEC code, thanks for the info how to replace with BaCon code, but might leave it as-is for now. But will post a url to here, comment in my code, for future reference.
Meanwhile, I hit a bug with CONCAT$, started another thread.
|
|
|
|
Post by Pjot on Feb 17, 2018 16:11:48 GMT 1
...I wonder what the repercussion is? If opendir() keeps re-running, without any closedir(), is that going to cause some resources somewhere to get used up? I would not expect so, but the kernel can just take an <x> amount of open handles. The total amount can be observed in the output of 'ulimit': In this output we can see there may be up to 1024 open (file) handles, so keeping handles open may eventually hit such limit. To my understanding it's just good practice to clean them up. BR Peter |
|
