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: Wed, 17 Jul 2024 19:31:15 +0200
Organization: A noiseless patient Spider
Lines: 170
Message-ID: <v78v53$1u50e$2@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> <v6r807$317bp$1@dont-email.me>
 <v6rrok$34t3j$1@dont-email.me> <v6thtn$3hc2e$1@dont-email.me>
 <v78hoq$1rcuu$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 17 Jul 2024 19:31:16 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="aa5b76c094c411454576763b940710a0";
	logging-data="2036750"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX191+RweJUR2+UATdfBRZfTnuiN8TmnqQPU="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:FgkTUMdEOpqVLcsAztVr2xqeHmg=
Content-Language: en-GB
In-Reply-To: <v78hoq$1rcuu$1@dont-email.me>
Bytes: 9114

On 17/07/2024 15:42, Bart wrote:
> On 13/07/2024 10:37, David Brown wrote:
> 
>> If you say stupid things, repeatedly,
> 
>> Start applying a bit of your intelligence (you say stupid things 
>> sometimes, but I know you are far from stupid), and you'll find the 
>> level of conversation going up.
>>
>>> I made the tweak to see how hard it would be to detect value-arrays 
>>> declared in parameter list (it was very easy), and what the 
>>> consequences would be on existing code (significant).
>>
>> No, the consequences are non-existent because no one uses your tool, 
>> and no one will ever copy that change in other tools (of significance).
> 
> You are spectacularly missing the point. IT DOESN'T WHOSE TOOL IT IS. 

Of course it matters.  /You/ can make changes to /your/ tool with a 
total disregard for the consequences.  You don't need to care about the 
effects it might have on the rest of the tool, because it's a small and 
self-contained tool.  You don't need to care about how it affects code 
other people have written over the decades - you are only interested in 
the code /you/ wrote (if you even care about that).  You don't need to 
care about how it will affect code other people will write in the 
future.  You don't need to care about how it might affect possible 
language changes in the future.

Basically, you can tweak your tool because you don't need to think 
further than your own nose.  And that's great for experimenting and 
playing around, but things get very different in the real world.

> Somebody could have done the same exercise with gcc, and come to the 
> same conclusion: too many programs use array parameters.

Did it never occur to you that most people use array parameters 
/correctly/ ?  Some people don't like using them (I'm not a big fan 
myself), but other people like them.

> 
> 
>>
>>>
>>> The example I posted showed a type (const char* x[]) where there was 
>>> no advantage to having that value array notation. Using 'const 
>>> char**' would be a more accurate description of the actual parameter 
>>> type.
>>>
>>
>> You can write your code the way you want to write it - it will not 
>> change the way anyone else writes their code.  It really is that 
>> simple.   Why is this so difficult for you to understand?
>>
>> Do you really suppose that if /you/ make "foo(char x[])" a syntax 
>> error in /your/ compiler, it will have the slightest effect on how 
>> other people write their C code?
> 
> What WOULD be the effect if a compiler did that? How would a particular 
> codebase be affected?

Code that uses that syntax would no longer work.  It's quite simple, really.

> 
> You can just modify a compiler and try it, which is what I did. What 
> difference does it make which compiler it is? You just have a blind, 
> irrational hatred for anything I do.
> 

No, I just have a more realistic idea of the influence you have, and of 
what is involved in changing real tools used by other people, or 
changing real languages used by other people.

You seem to imagine that you can pick something that you personally 
don't like in C, and solve the world's programming problems by making a 
change to your compiler.  I am pointing out that this is far from 
reality - even in cases where I might agree that the change would be an 
improvement to the C language.

> Another way to do it is for someone to painstakingly go through every 
> line of a codebase by hand, expanding macros and typedefs as needed, and 
> checking whether any parameters declared top-level array types.
> 
> I think if you were given that job to do,  then applying my toy compiler 
> wouldn't be so bad after all!

In what universe would it be a good idea to change compilers to stop 
them compiling existing correct working code?

> 
>> Or on what other C compilers do?  Or on how half a century of existing 
>> C code is written?
>>
>>
>> Personally, I don't like that C allows something that /looks/ like 
>> arrays can be passed to functions, but doesn't work that way.
> 
> gcc could conceivably have an option that detects and warns about that. 

It has warnings on the risky parts - such as applying "sizeof" to 
parameters declared to look like arrays.  That's all you need, really. 
(I'd prefer if that kind of warning were enabled by default.)

> Whoever is thinking about doing that might well do a test exactly like 
> mine.

No, they would be better off allowing established C syntax to work 
correctly while offering warnings where possible about likely code 
errors.  That's what real tools do.

> 
>>   I don't think I have ever written a function with an array-like 
>> parameter - I use a pointer parameter if I mean a pointer, or have the 
>> array wrapped in a struct if I want to pass an array by value.
> 
> So all /your/ code would still pass; great!

But that's just /my/ code.  I am not in favour of changes that break 
other people's code.

> 
>>   But I don't think my opinions make a difference to C, and even if I 
>> were elected dictator of C for a day, I don't think my opinions should 
>> count more than any one else's - including those that like the way C 
>> works here
> 
> Half of the programming language you call "C" is defined by the way you 
> invoke your compiler. So that already allows for myriad, slightly 
> different dialects.
> 

That's just nonsense - and you know it.

Flags, such as warnings, can lead to subsetting the language, not 
redefining it.

> Somebody had to think up all those options, and they would have been 
> influence by people's opinions. This is just one more, which I would 
> happily have as a default.
> 

If someone thought that it would be a good idea to warn about using 
array syntax in function parameter declarations, then it could certainly 
be added to tools as a /warning/.  That's totally different from 
disallowing it in the language.

File a "feature request" bug with gcc or clang asking for this warning, 
and you'll soon get comments about how likely it is that people will see 
it as a good idea.

> 
>> And I don't confuse my opinions or preferences with how C actually 
>> works and how it is actually defined, and I certainly don't spread 
>> such confusions and misunderstandings to others.
> 
> C does that well enough by itself. There are any number of behaviours 
> where: (1) saying nothing and passing; (2) warning and passing; (3) 
> reporting an error and failing are all perfectly valid.
> 
> You just choose which one you want, at least if using an equivocal 
> compiler like gcc.
> 
> This is like taking an examination and being able to choose how strictly 
> it should be marked! Yeah, I think I'll got a pass today...
========== REMAINDER OF ARTICLE TRUNCATED ==========