Re: [PATCH] man/: SYNOPSIS: Remove GNU forward-declarations of parameters for lengths of array parameters

[Alejandro Colomar <alx+linux-man@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2525 bytes --]

Hi Mark,

> Date: 2026-10-23 12:32:37-0700
> From: Mark Harris <mark.hsj@gmail.com>
>
[...]
> 
> I am not talking about someone writing new code that they will then
> try to compile at some point, I am talking about someone trying to
> understand or debug existing code.
> 
[...]
> trying to debug what is happening.  The man pages should do what it
> can to help them, not throw monkey wrenches in their path.

I see your concern.

> > You didn't take into account my other concerns, though.  I'd like to
> > hear your opinion about the concerns that letting users think that is
> > valid C might lead to them writing code that has UB (or logic errors).
> 
> An error in thinking that this is valid C syntax doesn't impact anyone
> trying to understand existing code, so I don't see the concerns as
> comparable.

It is actually valid syntax already.  It doesn't have the meaning that
we would be using for it, but it's valid syntax.

	int n = 42;

	int f(char a[n], int n);

	f(a, 7);

The array parameter is declared to have 42 elements, regardless of the
7 used at call site.

> If someone adds this in their own C code, and it has not been adopted
> as valid ISO C

The code above is valid C89, and it doesn't mean what one would
intuitively think it means.  That's my concern.  This is a source of
bugs.

Future extensions to the language will make that even more dangerous, by
making it more likely to compile:

	alx@debian:~/tmp$ cat param.c 
	int
	main(void)
	{
		int n = 42;

		int f(char a[n], int n)
		{
			return _Countof(a);
		}

		char s[] = "foo";

		return f(s, _Countof(s));
	}
	alx@debian:~/tmp$ /opt/local/gnu/gcc/cap/bin/gcc -Wall -Wextra param.c 
	param.c: In function ‘f’:
	param.c:6:30: warning: unused parameter ‘n’ [-Wunused-parameter]
	    6 |         int f(char a[n], int n)
	      |                          ~~~~^
	alx@debian:~/tmp$ ./a.out; echo $?
	42

> or as a compiler extension, then it is extremely likely
> to result in a compiler error.  If a likely compiler error was good
> enough for you when someone writes the arguments in the wrong order in
> their code due to confusion over the syntax, then I don't see why it
> wouldn't be satisfactory in this case where a compiler error is even
> more likely.  In both cases there is a chance that it will be accepted
> and do the wrong thing.

This analysis is wrong.  See above.


Have a lovely night!
Alex

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]