Page MenuHomeFreeBSD

libcasper: Use __VA_ARGS__ for function-like macros
AcceptedPublic

Authored by hrs on Jul 3 2024, 3:39 PM.
Tags
None
Referenced Files
Unknown Object (File)
Nov 7 2024, 7:47 PM
Unknown Object (File)
Nov 7 2024, 7:37 PM
Unknown Object (File)
Sep 23 2024, 12:22 AM
Unknown Object (File)
Sep 21 2024, 6:24 AM
Unknown Object (File)
Sep 20 2024, 7:37 AM
Unknown Object (File)
Sep 8 2024, 3:36 PM
Unknown Object (File)
Sep 7 2024, 11:11 PM
Unknown Object (File)
Jul 29 2024, 3:57 AM
Subscribers

Details

Reviewers
oshogbo
Summary

cap_net.h uses "#define cap_f(chan, a) f(a)" to call the conventional
service function with the first argument of cap_f() dropped for
compatibility with the environment where the casper service is
unavailable. However, this function-like macro does not work when the
arguments contains C99 compound literals, such as f(chan, (int[]){1,2,3}).
The following is a typical example:

	error = cap_getaddrinfo(capnet, "192.168.0.1", "100",
	    &(struct addrinfo){
		.ai_family = AF_INET,
		.ai_flags = AI_NUMERICHOST
	}, &res);

Using cap_f(chan, ...) and __VA_ARGS__ in C99 seems a reasonable solution
for this problem. While there is a workaround using parenthesis around
the compound literal like f(chan, ((int[]){1,2,3})), it is not intuitive
and the above example works when the cap_net is available and f() is
defined as a function.

The possible moot point is that __VA_ARGS__ cannot control how many
arguments are passed at the macro level, and "chan" is not protected.
However, "chan" is less likely to be written in compound literal, and
the function prototype should check the remaining arguments.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 58478
Build 55366: arc lint + arc unit

Event Timeline

hrs requested review of this revision.Jul 3 2024, 3:39 PM
hrs edited the summary of this revision. (Show Details)

Seems reasonable, thanks!

This revision is now accepted and ready to land.Jul 3 2024, 3:42 PM