[PATCH v2] close_range: fd and max_fd are unsigned

[Dmitry V. Levin]

On Tue, May 04, 2021 at 07:53:59PM +0000, Alyssa Ross wrote:
> The distinction is important, because close_range(2) says that having
> max_fd < fd is an error, but if you give the kernel 1U + INT_MAX as
> max_fd, it'll interpret it as unsigned.
> 
> Since we're working with ranges of file descriptors here, the
> particular properties of only the start and end file descriptors
> aren't really relevant, so it doesn't matter that we're losing fancy
> file descriptor printing in making this change.
> ---
> v1: https://lists.strace.io/pipermail/strace-devel/2021-March/010459.html
[...]
>  int
>  main(void)
>  {
> -	SKIP_IF_PROC_IS_UNAVAILABLE;
> +	k_close_range(4294967294, 4294967295, 1);
> +	printf("close_range(4294967294, 4294967295, 0x1 /* CLOSE_RANGE_??? */) = %s\n", errstr);
>  
> -	const int fd0 = dup(0);
> -	const int fd7 = dup(7);
> -	const int fd7_min = MIN(7, fd7);
> -	const int fd7_max = MAX(7, fd7);
> +	k_close_range(4294967295, 4294967294, 2);
> +	printf("close_range(4294967295, 4294967294, CLOSE_RANGE_UNSHARE) = %s\n", errstr);
>  
> -	k_close_range(-2, -1, 1);

Why do you replace -2 and -1 with 4294967294 and 4294967295?
Aren't -2U and -1U more readable?



-- 
ldv