hello all. I have a question about one of the C header files

the use of SIG_DFL at github.com/the-tcpdump-group/tcpdump/blob/master/tcpdump.c#L2382 always generates a warning from Clang (but not GCC)

tcpdump.c:2382:51: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]

/usr/include/sys/iso/signal_iso.h under normal conditions defines it as follows: #define SIG_DFL (void(*)())0

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

I can imagine there are quite a few programs that use that header

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

perhaps that header needs to be changed to define SIG_DFL etc. as (void(*)(int))(0)

Woodstock: maybe not, please see the comment starting at line 75 of /usr/include/sys/signal.h

although defining and using this instead silences the warning: #define MY_SIG_DFL (void(*)(int))0

well, a correct solution for SIG_DFL etc. would probably involve just the same #if's as the struct sigaction declaration

however, in support of your point, making the following change now generates the same warning for the program's own function:

-(*setsignal (int sig, void (*func)(int)))(int)

+(*setsignal (int sig, void (*func)(int)))()

yes, they tend to want proper prototyping nowadays, so 'type name()' style constructs are causing trouble. it's not 80's any more:)

alright, if the consensus is the long-term fix should be that, what would be the next step? opening a bug report?

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.

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

so I am prototyping a workaround that will disable specifically -Wstrict-prototypes from Clang on illumos for these two specific lines of code

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.

the bug report is being composed

the goal is to compile tcpdump with -Werror on illumos

the two warnigns at 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

Yup, makes sense. Appreciate you looking at fixing that.

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

s/I am competent/I am not competent/ above

(whilst testing, found an issue in my earlier commit to libpcap, of course)

Gotcha, we'll make sure to look at it.

Thanks for reporting this.

illumos.org/issues/16344 it is then, I am leaving a reference in the comments for tcpdump workaround

→ BUG 16344: -Wstrict-prototypes warnings about SIG_DFL, SIG_ERR, SIG_IGN and SIG_HOLD signal constants (New)

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

C23 allows void (*func)(...)

(unclear if that would help)

FreeBSD does this: typedef void __sighandler_t(int);

NetBSD does this: #define SIG_DFL ((void (*)(int)) 0)

OpenBSD does this: #define SIG_DFL (void (*)(int))0

Haiku does this: typedef void (*__sighandler_t)(int);

Solaris 11.4 does this (unless C++): typedef void (*__sighandler_t)(int);

GNU/Linux does this: typedef void (*__sighandler_t) (int);

AIX 7.3 does this (unless _NONSTD_TYPES): #define SIG_DFL ((void (*)(int))0)

GNU/Hurd does this: typedef void (*__sighandler_t) (int);

(there must be something in macOS, HP-UX and Windows, but I cannot tell now)

that's not what I see in the Solaris 11.4 headers - ours is more like NetBSD but with extra #defines

#define SIG_PF void (*)(int)

#define SIG_DFL ((SIG_PF)0)

(for the non-C++ case, C++ uses typedefs)

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

and yeah, 11.4 changed it to fix compiler warnings like that

→ OpenSolaris issue 4193401: signal.h is not ISO 9899 compliant. (Accepted)

Are there any 0xide related channels on libera.chat?

alanc: you are welcome to update my bug report, it seems the fix would need to go through some pro et contra

bug report seems fine to me, I don't think I can edit it anyway

I suspect the "Quote" hyperlink on the right is meant to mean "reply" or "comment" rather than "replace the description"

[illumos-gate] 15639 want more NPT bit operations in bhyve -- Patrick Mooney <pmooney⊙pc>

for posterity, the -Wstrict-prototypes workaround is the-tcpdump-group/tcpdump #1138

thanks for the feedback to everyone who cared to comment

[illumos-gate] 16276 acct: type of parameter defaults to 'int' -- Toomas Soome <tsoome⊙mc>

[illumos-gate] 16254 expr: type of 'oper' defaults to 'int' -- Toomas Soome <tsoome⊙mc>