Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: James Kuyper <jameskuyper@alumni.caltech.edu>
Newsgroups: comp.lang.c
Subject: Re: Results of survey re. a new array size operator
Date: Sat, 25 Jan 2025 00:06:23 -0500
Organization: A noiseless patient Spider
Lines: 40
Message-ID: <vn1rgg$2loom$1@dont-email.me>
References: <87a5bgsnql.fsf@gmail.com> <vn066i$28bkd$2@dont-email.me>
 <20250124121027.691@kylheku.com> <vn1evg$2g0m7$1@dont-email.me>
 <20250124181810.43@kylheku.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 25 Jan 2025 06:06:25 +0100 (CET)
Injection-Info: dont-email.me; posting-host="754b368ecbae64992e68fbeb07ea14bc";
	logging-data="2810646"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19DDSx93mbDZyJGxswmJ3G8Ey7+YUW4r60="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:ODLIjrth71GVBalPy1vr3q/kuXo=
In-Reply-To: <20250124181810.43@kylheku.com>
Content-Language: en-US
Bytes: 2905

On 1/24/25 21:40, Kaz Kylheku wrote:
> On 2025-01-25, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
....
>> C code is software, and so are C implementations, so I'm not sure what
>> that has to do with anything.
>>
>> The committee has explicitly stated a
>> priority between those two kinds of software: "existing user code
>> matters; existing implementations don't".
> 
> Ensuring existing user code keeps working doesn't have to be a
> responsibility of ISO C.

True. Making it the responsibility of C was a decision made by the C
committee, not something they had to do. That decision makes a key part
of C's identity. If you don't like that decision, I strongly recommend
choosing a language managed by an organization that attaches less
importance to backwards compatibility.

....
> ISO C has not remained perfectly backward comaptible, so why
> pretend to be the keepers of backward compatibility?

They don't. They "pretend" to be people who place a high, but not
absolute, priority on maintaining backwards compatibility. In fact, they
"pretend" it so well that it's actually the reality.

....
>> Backwards compatibility doesn't mean that you can still build your
>> program using an older version of the language.
> 
> That's not all it means, sure.

It's not what it means at all. Backwards compatibility is a relationship
between two different versions of the standard. If one of those two
versions is not, in any way, involved, the concept is meaningless. When
you use a modern compiler that has a mode where it can compile C2023
code, but use it in a different mode where it supports C90, it isn't a
C2023 compiler that's backwards compatible with C90. In that mode, it is
simply a C90 compiler.