Re: technology discussion → does the world need a "new" C ?

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

You really don't understand how people use compilers, do you?  You know how /you/ use /your/ language and /your/ tools, but the idea of there being other programmers in the world, with different needs and preferences, seems beyond you sometimes.