Path: ...!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 07:53:01 +0200
Organization: A noiseless patient Spider
Lines: 39
Message-ID: <v6qgbt$2t6p7$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 12 Jul 2024 07:53:01 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0d63f29bdb823407c5eda4702e8b85d8";
	logging-data="3054375"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/ZZZjyrRgm6+FHMR6nfVoBrFpeah9/yfM="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:jjdSO2HhgRV5lMIHNBK127YI25g=
Content-Language: en-GB
In-Reply-To: <v6pfo3$2jijk$2@dont-email.me>
Bytes: 3361

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?  Or is this a serious 
question about the historical process of design decisions in C?  My only 
guess here - and it is only a guess - is it goes back to the way 
function parameters were written in K&R C before prototypes, and 
supported because in C, declarations follow usage.  You can write B[10] 
whether you have "int B[20]" or "int * B", so it seems natural that you 
could use either form when declaring the parameter.

(Note that I too would have preferred a different syntax.  IMHO it would 
have been better either to allow passing arrays by value in some way, or 
not to allow code that /looks/ like it passes arrays.)