Path: ...!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: =?UTF-8?Q?Re=3A_technology_discussion_=E2=86=92_does_the_world_need?=
 =?UTF-8?B?IGEgIm5ldyIgQyA/?=
Date: Fri, 12 Jul 2024 12:03:50 +0100
Organization: A noiseless patient Spider
Lines: 53
Message-ID: <v6r2im$30a9n$1@dont-email.me>
References: <v66eci$2qeee$1@dont-email.me> <v6gl83$s72a$1@dont-email.me>
 <v6h8ao$ur1v$1@dont-email.me> <v6jhk3$1drd6$1@dont-email.me>
 <v6jiud$1dsjb$1@dont-email.me> <877cdur1z9.fsf@bsb.me.uk>
 <v6joi4$1epoj$1@dont-email.me> <871q42qy33.fsf@bsb.me.uk>
 <v6k6i0$1h4d3$1@dont-email.me> <87ed82p28y.fsf@bsb.me.uk>
 <v6m03l$1tf05$1@dont-email.me> <87r0c1nzjj.fsf@bsb.me.uk>
 <v6m716$1urj4$1@dont-email.me> <86ikxd8czu.fsf@linuxsc.com>
 <v6mggd$20g3f$1@dont-email.me> <20240710213910.00000afd@yahoo.com>
 <v6mm02$21cpb$1@dont-email.me> <865xtc87yo.fsf@linuxsc.com>
 <v6ol14$2fdrj$1@dont-email.me> <87msmnu5e3.fsf@nosuchdomain.example.com>
 <v6pdcf$2jijk$1@dont-email.me> <87frsfu0yp.fsf@nosuchdomain.example.com>
 <v6pfo3$2jijk$2@dont-email.me> <v6qgbt$2t6p7$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 12 Jul 2024 13:03:51 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="70309d0afdade4e9fabfb798d5d70205";
	logging-data="3156279"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/pw8JLXOAZBXG+GQNF4ZVJ"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:6zyRJDwuJNvYKvJIeT8HqG+fuCA=
In-Reply-To: <v6qgbt$2t6p7$1@dont-email.me>
Content-Language: en-GB
Bytes: 3453

On 12/07/2024 06:53, David Brown wrote:
> On 11/07/2024 22:36, bart wrote:
>> On 11/07/2024 21:29, Keith Thompson wrote:
>>> bart <bc@freeuk.com> writes:
>>
>>>> The language could have helped a little by making this invalid:
>>>>
>>>>     int A[20];
>>>>
>>>>     void F(int B[20]) {}
>>>>
>>>> The type of B looks just like that of A, but it isn't; the T[N] type
>>>> is silently changed to T*. The language could insist that you write:
>>>>
>>>>     void F(int* B) {}
>>>
>>> But it doesn't.  Why should we waste time in comp.lang.c explaining how
>>> C *could* have been defined?  It's hard enough to explain how it
>>> actually is defined, especially with your contributions.
>>>
>>>> This way, it is far clearer that a pointer is being passed, and 'pass
>>>> by value' now makes more sense. The way B will be used is now
>>>> consistent with the same declaration anywhere else.
>>>
>>> But that's not C.
>>
>> Why isn't it C?
> 
> Are you trying to blame us for how C is defined?

KT has chosen not to answer, and now you are evading it too. I'm asking 
why this:

      void F(int* B) {}

is 'not C' according to KT.

To be clear, I was proposing that:

  void F(int B[20])

is an error, and requiring people to write:

  void F(int* B) {}

instead. I tried to enforce that in my C compiler, and it was a one-line 
change. But it can only be used for new programs, and so much existing 
code uses those value-array declarations, for example:

LUALIB_API int (luaL_checkoption) (lua_State *L, int arg, const char *def,
                                    const char *const lst[]);