Re: [patch V3 01/10] cleanup: Provide retain_ptr()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2025-03-17 at 14:29 +0100, Thomas Gleixner wrote:
[...]
> +/*
> + * Only for situations where an allocation is handed in to another
> function
> + * and consumed by that function on success.
> + *
> + *	struct foo *f __free(kfree) = kzalloc(sizeof(*f),
> GFP_KERNEL);
> + *
> + *	setup(f);
> + *	if (some_condition)
> + *		return -EINVAL;
> + *	....
> + *	ret = bar(f);
> + *	if (!ret)
> + *		retain_ptr(f);
> + *	return ret;
> + */
> +#define retain_ptr(p)				\
> +	__get_and_null(p, NULL)

This doesn't score very highly on the Rusty API design scale because it
can be used anywhere return_ptr() should be used.  To force the
distinction between the two cases at the compiler level, should there
be a cast to void in the above to prevent using the return value?

Regards,

James






[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux