11:21:16 hello all. I have a question about one of the C header files 11:21:48 the use of SIG_DFL at https://github.com/the-tcpdump-group/tcpdump/blob/master/tcpdump.c#L2382 always generates a warning from Clang (but not GCC) 11:22:09 tcpdump.c:2382:51: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes] 11:22:58 /usr/include/sys/iso/signal_iso.h under normal conditions defines it as follows: #define SIG_DFL (void(*)())0 11:24:05 so I wonder, if the header file does it the right way, is there some non-obvious way to use the macro to compile without the warning? the same applies to SIG_ERR in the same file 11:24:37 I can imagine there are quite a few programs that use that header 11:34:54 although, as I was trying to formulate the problem, I began to suspect the warning may be caused by the manner of use of the macro in tcpdump.c rather than its definition in the header 11:37:28 perhaps that header needs to be changed to define SIG_DFL etc. as (void(*)(int))(0) 11:47:44 Woodstock: maybe not, please see the comment starting at line 75 of /usr/include/sys/signal.h 11:50:15 although defining and using this instead silences the warning: #define MY_SIG_DFL (void(*)(int))0 11:51:18 well, a correct solution for SIG_DFL etc. would probably involve just the same #if's as the struct sigaction declaration 11:53:37 however, in support of your point, making the following change now generates the same warning for the program's own function: 11:53:40 -(*setsignal (int sig, void (*func)(int)))(int) 11:53:40 +(*setsignal (int sig, void (*func)(int)))() 12:06:51 yes, they tend to want proper prototyping nowadays, so 'type name()' style constructs are causing trouble. it's not 80's any more:) 12:15:53 alright, if the consensus is the long-term fix should be that, what would be the next step? opening a bug report? 13:45:59 Denis: Filing a bug always helps. I think one thing that'll be useful to know is if it's something you want to pursue fixing or if you want someone else to. 13:47:38 rmustacc: I am competent enough to make the change in illumos in a way that would be safe for all other users, also the fix will take time to propagate downstream and into GA releases 13:48:19 so I am prototyping a workaround that will disable specifically -Wstrict-prototypes from Clang on illumos for these two specific lines of code 13:48:52 Well, just a question of what you'd prefer to do. If not, I can try to add it to a queue to look at or someone else may be able to. 13:49:09 the bug report is being composed 13:49:53 the goal is to compile tcpdump with -Werror on illumos 13:51:41 the two warnigns at https://github.com/the-tcpdump-group/tcpdump/blob/master/build.sh#L39 (line numbers no longer accurate after code churn) are currently the only two exemptions, every other OS was made warning-free earlier 13:52:56 Yup, makes sense. Appreciate you looking at fixing that. 13:53:48 since the problem is in the OS, it makes the most sense to silence these two specific instances now so the entire build can be made -Werror, then as and if illumos has a fix and the fix has propagated, the silencing directives can go away 13:54:48 s/I am competent/I am not competent/ above 13:59:48 (whilst testing, found an issue in my earlier commit to libpcap, of course) 14:04:37 Gotcha, we'll make sure to look at it. 14:04:41 Thanks for reporting this. 15:32:09 https://www.illumos.org/issues/16344 it is then, I am leaving a reference in the comments for tcpdump workaround 15:32:13 → BUG 16344: -Wstrict-prototypes warnings about SIG_DFL, SIG_ERR, SIG_IGN and SIG_HOLD signal constants (New) 15:53:12 the wrinkle is how to deal with the rarely-used extra handler arguments. if it were not for that, we could just take the code currently under #ifdef __cplusplus 15:56:45 C23 allows void (*func)(...) 15:57:08 (unclear if that would help) 16:04:04 FreeBSD does this: typedef void __sighandler_t(int); 16:05:01 NetBSD does this: #define SIG_DFL ((void (*)(int)) 0) 16:05:43 OpenBSD does this: #define SIG_DFL (void (*)(int))0 16:06:36 Haiku does this: typedef void (*__sighandler_t)(int); 16:08:24 Solaris 11.4 does this (unless C++): typedef void (*__sighandler_t)(int); 16:09:12 GNU/Linux does this: typedef void (*__sighandler_t) (int); 16:10:52 AIX 7.3 does this (unless _NONSTD_TYPES): #define SIG_DFL ((void (*)(int))0) 16:12:42 GNU/Hurd does this: typedef void (*__sighandler_t) (int); 16:14:35 (there must be something in macOS, HP-UX and Windows, but I cannot tell now) 16:49:44 that's not what I see in the Solaris 11.4 headers - ours is more like NetBSD but with extra #defines 16:49:56 #define SIG_PF void (*)(int) 16:49:58 #define SIG_DFL ((SIG_PF)0) 16:50:30 (for the non-C++ case, C++ uses typedefs) 16:57:09 alanc: I stand corrected, that's a buffer hangover from Haiku because I did not realise my selection did not make it out of the Solaris VM 17:20:19 and yeah, 11.4 changed it to fix compiler warnings like that 17:21:46 https://illumos.org/opensolaris/bugdb/bug.html#!4193401 17:21:47 → OpenSolaris issue 4193401: signal.h is not ISO 9899 compliant. (Accepted) 18:01:27 Are there any 0xide related channels on libera.chat? 18:08:36 alanc: you are welcome to update my bug report, it seems the fix would need to go through some pro et contra 18:09:58 bug report seems fine to me, I don't think I can edit it anyway 18:21:42 I suspect the "Quote" hyperlink on the right is meant to mean "reply" or "comment" rather than "replace the description" 20:20:30 [illumos-gate] 15639 want more NPT bit operations in bhyve -- Patrick Mooney 20:23:21 for posterity, the -Wstrict-prototypes workaround is https://github.com/the-tcpdump-group/tcpdump/pull/1138 20:23:44 thanks for the feedback to everyone who cared to comment 21:11:18 [illumos-gate] 16276 acct: type of parameter defaults to 'int' -- Toomas Soome 22:35:50 [illumos-gate] 16254 expr: type of 'oper' defaults to 'int' -- Toomas Soome