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

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