[PATCH] tools/sched_ext: Fix get_prandom_u64() prototype

[PATCH] tools/sched_ext: Fix get_prandom_u64() prototype

[Cheng-Yang Chou]

In C99 (Sec 6.7.5.3), an empty parameter list in a declaration leaves
the parameter types unspecified (K&R style), not explicitly zero.
Consequently, the compiler would silently accept arbitrary arguments
passed to the function.

Declare the function with (void) to form a proper prototype asserting
it takes no arguments.

Signed-off-by: Cheng-Yang Chou <yphbchou0911@gmail.com>
---
 tools/sched_ext/include/scx/common.bpf.h | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/tools/sched_ext/include/scx/common.bpf.h b/tools/sched_ext/include/scx/common.bpf.h
index a63a98a96b86..99b1a94097e7 100644
--- a/tools/sched_ext/include/scx/common.bpf.h
+++ b/tools/sched_ext/include/scx/common.bpf.h
@@ -621,7 +621,6 @@ static inline bool time_in_range_open(u64 a, u64 b, u64 c)
 	return time_after_eq(a, b) && time_before(a, c);
 }
 
-
 /*
  * Other helpers
  */
@@ -870,11 +869,10 @@ static inline u64 scale_by_task_weight_inverse(const struct task_struct *p, u64
 	return value * 100 / p->scx.weight;
 }
 
-
 /*
  * Get a random u64 from the kernel's pseudo-random generator.
  */
-static inline u64 get_prandom_u64()
+static inline u64 get_prandom_u64(void)
 {
 	return ((u64)bpf_get_prandom_u32() << 32) | bpf_get_prandom_u32();
 }
-- 
2.48.1

Re: [PATCH] tools/sched_ext: Fix get_prandom_u64() prototype

[Andrea Righi]

Hi,

On Sun, Mar 08, 2026 at 09:06:38PM +0800, Cheng-Yang Chou wrote:
> In C99 (Sec 6.7.5.3), an empty parameter list in a declaration leaves
> the parameter types unspecified (K&R style), not explicitly zero.
> Consequently, the compiler would silently accept arbitrary arguments
> passed to the function.
> 
> Declare the function with (void) to form a proper prototype asserting
> it takes no arguments.
> 
> Signed-off-by: Cheng-Yang Chou <yphbchou0911@gmail.com>

I understand the motivation, but changes like this don't fix real issues or
provide any measurable benefit. Patches consume maintainer and reviewer
bandwidth, so it's usually best to focus on changes that fix real bugs or
provide clear improvements.

If you encounter a real issue or can show a measurable improvement (with
traces or numbers), patches addressing that would be much more useful.

Thanks,
-Andrea

> ---
>  tools/sched_ext/include/scx/common.bpf.h | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/tools/sched_ext/include/scx/common.bpf.h b/tools/sched_ext/include/scx/common.bpf.h
> index a63a98a96b86..99b1a94097e7 100644
> --- a/tools/sched_ext/include/scx/common.bpf.h
> +++ b/tools/sched_ext/include/scx/common.bpf.h
> @@ -621,7 +621,6 @@ static inline bool time_in_range_open(u64 a, u64 b, u64 c)
>  	return time_after_eq(a, b) && time_before(a, c);
>  }
>  
> -
>  /*
>   * Other helpers
>   */
> @@ -870,11 +869,10 @@ static inline u64 scale_by_task_weight_inverse(const struct task_struct *p, u64
>  	return value * 100 / p->scx.weight;
>  }
>  
> -
>  /*
>   * Get a random u64 from the kernel's pseudo-random generator.
>   */
> -static inline u64 get_prandom_u64()
> +static inline u64 get_prandom_u64(void)
>  {
>  	return ((u64)bpf_get_prandom_u32() << 32) | bpf_get_prandom_u32();
>  }
> -- 
> 2.48.1
> 

Re: [PATCH] tools/sched_ext: Fix get_prandom_u64() prototype

[Cheng-Yang Chou]

On Sun, Mar 08, 2026 at 03:01:59PM +0100, Andrea Righi wrote:
> Hi,
> 
> On Sun, Mar 08, 2026 at 09:06:38PM +0800, Cheng-Yang Chou wrote:
> > In C99 (Sec 6.7.5.3), an empty parameter list in a declaration leaves
> > the parameter types unspecified (K&R style), not explicitly zero.
> > Consequently, the compiler would silently accept arbitrary arguments
> > passed to the function.
> > 
> > Declare the function with (void) to form a proper prototype asserting
> > it takes no arguments.
> > 
> > Signed-off-by: Cheng-Yang Chou <yphbchou0911@gmail.com>
> 
> I understand the motivation, but changes like this don't fix real issues or
> provide any measurable benefit. Patches consume maintainer and reviewer
> bandwidth, so it's usually best to focus on changes that fix real bugs or
> provide clear improvements.
> 
> If you encounter a real issue or can show a measurable improvement (with
> traces or numbers), patches addressing that would be much more useful.
> 
> Thanks,
> -Andrea

Understood.
Again, thanks for the explaination.

-- 
Thanks,
Cheng-Yang