Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
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 14:36:23 +0200
Organization: A noiseless patient Spider
Lines: 84
Message-ID: <v6r807$317bp$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>
 <v6r2im$30a9n$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 14:36:23 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0d63f29bdb823407c5eda4702e8b85d8";
	logging-data="3186041"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19S6WWVIpMwwkoKP1WoI2ldRn7Dh3E4FAk="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:whK582D885kpoLxer9tSqYahWCc=
In-Reply-To: <v6r2im$30a9n$1@dont-email.me>
Content-Language: en-GB
Bytes: 4703

On 12/07/2024 13:03, bart wrote:
> 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 am not evading it in any way.  I answered, and you snipped the answer.

> I'm asking 
> why this:
> 
>       void F(int* B) {}
> 
> is 'not C' according to KT.

Keith did not say anything of the sort.

Why do you keep ignoring what people write, then argue against things 
that no one said?

> 
> 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. 

And to be clear, no one has said that would be a bad idea (which does 
not mean that no one /thinks/ it would be a bad idea).  But it is not 
how C is defined as a language, and the C language - its compilers and 
existing code base - is not going to change on the whims of some guy off 
the internet who can't be bothered to learn the language properly.

> 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[]);
> 
> 

One person's private sort-of-C compiler is of no more relevance to the C 
community than one person's private language.  You are welcome to make 
as many non-conforming changes to your own tools as you like, but they 
do not make a difference to C.  No one else will ever use your tool, so 
no one else will ever care about any incompatible changes you make to 
it.  If /you/ are happier having such changes in your tools, then that 
is great for you.